Eh, not really then. If you have some behavior in those 50 copy/pastes that needs to be deleted, you’ve got to delete it 50 times. That’s not easier at all.

Customers tend to view quality more holistically than that, though. Not a lot of people are going to flip their conception of product quality on a single change, but will after a long series of changes. Once a company gets that reputation for poor quality, it’s not as simple as reversing the last corner they cut. It’s a hole that takes a lot of changes to dig out of. More than most companies are willing to reverse.

It does and they’re kinda weird (if you’re used to more like Java-style interfaces). It flips the dependency between the interface and implementor on its head. Worth looking it up, it’s interesting.

Which one is important is going to depend on the context for sure.

If it’s an open source library, they probably won’t care about 1.

If you’re working on internal software used by other developers within the company, management probably really does care about 1 because it’s going to impact their timelines.

If you’re working on a proprietary user-facing API, then even if it doesn’t cost your company anything management might still care because it could piss off valuable customers.

I think that, for what ever decision OP is trying to make, looking at that context is more important than quibbling over what exactly constitutes a “breaking change.”