I think it is worth distinguishing proper opaque abstractions, that are defined by a contract, from convenience macro-like "abstractions" that are defined by th

I think it is worth distinguishing proper opaque abstractions, that are defined by a contract, from convenience macro-like "abstractions" that are defined by their implementation. The former are for abstracting different implementations behind and interface and/or decoupling, and require thought, planning, and careful consideration for their evolution. The latter are purely for convenience, to save some typing, some mental overhead when understanding code (although they can increase it just as well) and to centralize minor bug fixes or common features. For long term evolution and divergence, these abstractions should simply be macro-expanded instead of trying to refit them for the new requirements. Of course reality is a continuum.