The extra context I'd add to your statements is that poor choices of abstraction are overwhelmingly more common than good ones, and that insiders learn to live with them.
There's definitely a tendency for that to happen, I agree. If nothing else, we often don't know what good abstractions will look like yet in the early days of a project.
Even if we do, the most useful abstractions might change as the project evolves. Fortunately, the kinds of abstractions that tend to be most useful for hiding a lot of complexity also tend to be quite stable, in the sense that while they might be extended or generalised as the project develops, it is rarely necessary to severely break backward compatibility.
In an ideal world, we could definitely have more natural tools for things like refactoring, source control and diffs/merges, though, to lower the kinds of barriers you mentioned and promote willingness to refine the design and keep it clean as a project develops.
I think you have interesting ideas and laudable goals. It's nice to see some promotion of good coding style that goes beyond basics like how to choose good names (which are also important, of course, but well covered by existing material). It's also nice to see some recognition that what may be good for working with code in the small may not always be good for working with code in the large, which I think is not as well understood as it could be in our industry, to our cost.
Curiously, while I agree with many of the goals and much of your analysis of the problems, my own search for solutions has gone in almost the opposite direction. I tend to emphasize good modular design and clearly specified interfaces more as a result and to rely on ad-hoc examples and test suites less. It's not that I have a problem with the latter or don't use them, just that I don't find them sufficiently general and unambiguous on their own. So instead, my own thinking has often been about how we might improve the way we define interfaces and then connect modules using them, including evolution and being able to migrate code using a module from one interface to another efficiently and reliably if and when that becomes useful.
It's fascinating, and perhaps a little scary, that despite being interested in similar areas and having reached some similar conclusions about problems that it would be helpful to solve, we can still look in such different places for those solutions. I suppose that's a sign of how "young" our understanding of how to build software still is and how much we still have to figure out. Perhaps your project will bring some of those answers, and I wish you luck with it.
There's definitely a tendency for that to happen, I agree. If nothing else, we often don't know what good abstractions will look like yet in the early days of a project.
Even if we do, the most useful abstractions might change as the project evolves. Fortunately, the kinds of abstractions that tend to be most useful for hiding a lot of complexity also tend to be quite stable, in the sense that while they might be extended or generalised as the project develops, it is rarely necessary to severely break backward compatibility.
In an ideal world, we could definitely have more natural tools for things like refactoring, source control and diffs/merges, though, to lower the kinds of barriers you mentioned and promote willingness to refine the design and keep it clean as a project develops.