1) Sure. Most of us do not. So why should we care and/or trade other stuff for compile time improvements?
2) That's when you don't have a module loading system and have to build everything everytime.
Which is an no-op answer. That can be the answer for any kind of engineering decision, including the most idiotic ones.
We're concerned with what's best here, not merely with what has been decided.
>Don't like it, feel free to fork it
Another BS non answer.
Yeah I was being facetious with my original reply, and frankly I get your point, I was pointing out however that you _can_ fork it to make it work the way you'd prefer. If you truly don't want to (or can't) do that, then open a ticket or send something to a mailing list.
If this really matters to you, do something about it that can make an actual difference.
Or use gccgo, which piggybacks off of the many optimizations that have been used in the gcc collection[0] over the years.
When discussing compilation of Go, people here often seem to forget that two first-class compilers exist for the language.
[0] Yes, I am aware that this is like saying "ATM machine"
2) This is about the linker, not the compiler. You should compare the compilation times with the linking times instead of making assumptions.