You changed the premise. What's being made better? The change being discussed is broken phones. That's not better. Hypothetically, that could be from a change that makes something better. Is there any reason to believe it though?
Fun fact, it'd actually be illegal for Apple to disable devices if it detects a replacement part.
There are anti-trust laws against 'tying agreements', and forcing consumers to only buy components from Apple (due to tie-in) would be violating those laws.
That said, those laws don't say anything about having to interoperate with an inferior part.
So assuming Apple isn't willfully violating anti-trust laws, we can be fairly sure the change was intended to improve some aspect of the touch controller.
Note: There are exceptions if the tying serves a purpose other than maintaining a monopoly (such as the security pairing between the TouchID sensor and FaceID camera).
I had my rain sensing windshield replaced. The insurance company refused to replace with an OEM windshield. The windshield company said it would be fine.
It was not fine. Rain sensing didn't work again for the rest of the time I owned the car.
You can do whatever you want to it! But would you expect an NVidia graphics card to work with AMD drivers? The controller isn't the one the drivers were written for, so it breaks. Not surprising.
I think this analogy has gone off course a bit. But I do think a manufacturer providing automatic irreversible updates has an obligation to ensure, as best as possible, that the device continues to work with that update. If it worked yesterday, it should work tomorrow, period.
It would be perfectly reasonable to not force updates and allow users to continue with the current version forever if that keeps them running. But it's not reasonable to just break people's functional devices with an unavoidable update.
How would the manufacturer know you were using a non-OEM part, though? As far as they're concerned their parts support so-and-so protocol, so they should be able to use it.
This isn't a black and white issue. Some degree of compromise is needed as neither side is 100% right. What seems reasonable is a degree of resiliency be built in - so if the protocol worked on a subset of features, you don't brick it as you expand to new ones, you merely degrade.
It's not a perfect analogy, but the rules on radio interference with devices spring to mind: you need to cope with some interference and you need to not emit it. This results in a more stable ecosystem, even though you could sensibly argue that if one side is stuck to absolutely, the need for the other wouldn't exist.
They don't and shouldn't. But they should and can detect if a pending update will break your device, or downgrade more gracefully when their software runs on hardware that is missing some expected features that were previously unused.
I assume this wasn't intentional (Hanlon's razor).
But even if it wasn't, it's not entirely outrageous to predicate continued software support on some terms. The only problem then would be not making those terms clear up-front.
