Hey Dylan!
A very interesting question! We didn't find much of trouble with it, since the components are well differentiated. So if you override the Breadcrumbs component, then you have the logic and the presentation both shadowed, so the parent component that "calls" it, will call a valid full working version of the component, and it will work. If at some point Volto updates the Breadcrumbs component and introduces a new feature, we take care it's not breaking and complies with the existing API (eg. actions and reducers) so the new and the shadowed component would work both although the shadowed component won't have the new feature, for sure.
Also, experience tells that you tend to provide and write your own components (eg. footer) then it becomes more than an override, it becomes a "fill-slot" where you drop in any component you want. The component nature has an interesting duality from the "overriding just a template" in the JBOT approach. It's far more similar in the way of using a layer to override a full Zope view where you override the logic and the template, than the raw JBOT concept.
We take close care that the internal API (actions and reducers) do not change, and if a change is required, then we issue a major version and document it properly.
We are aware that we need to split down some components, that with time grew big, and try to separate logic from presentation so you could only shadow the presentation part, if required. That would improve the developer experience for sure, although might imply a breaking change on its own.
We are also aware that we need to introduce insertion points (in a viewlet manager fashion) that would make not required the forced override of key components (App, View etc). They are already in the roadmap.
"Implementations may change over time, the good concepts and values remains"