The inevitability at this time seems to be that the desired function of large, successful systems will evolve over time. This is the root cause of larger system

The inevitability at this time seems to be that the desired function of large, successful systems will evolve over time. This is the root cause of larger system rewrites being so common and (at this time) largely inevitable. But that is also the appeal of strong subsystems that last and can evolve. Language runtimes, libraries, infrastructure components like databases. The can largely persist, but their suitability to various systems will shift as the system themselves change. One must consider that many approaches, even if better for the long-run would have near term costs in terms of additional effort, or training, operational support or even hardware needs. > That's so wasteful that it seems irresponsible to let personal preference or emotional investment influence foundational decisions that might later prove wrong, requiring a rewrite Not so, since it is likely the case that the requirements and system's function will change, the primary objective is the efficient production of first working version. Personal productivity, satisfaction and good team dynamics probably trump most technical consideration beyond broad strokes (writing for web in assembly is probably a bad idea, but django vs. rails vs. go microservies is probably moot). Furthermore, one must consider the corollary to the initial presumption: most new projects either aren't successful or aren't long lived. So while if you have strong evidence that a system will be successful and long lived further investment in technical deliberation in making the choice of platform, toolset and architecture would be warranted - it is much more likely no such evidence exists. And therefore the initial investment is the only one likely to be made, so longer term confederations matter not (again beyond some basics and near universal best practices).