They could do the equivalent of static linking and include the necessary components in the browser instead of the OS.
That's more or less what the Utilu IE Collection does I think.
So on the older operating systems, programs that shipped with the OS will be embedding the browser as a COM component, usually for help purposes. If they're rendering local HTML (or generated HTML!) then they require that to keep working. So that particular interface has to be maintained, making it very difficult to upgrade.
Microsoft were kind of correct in the "browser choice" lawsuit that they'd used the browser as an OS component, and everyone else was correct that this was kind of a bad idea.
On the other hand, how do you embed a browser component in a forward-compatible way?
Android uses a WebView component. If an app wants to display a webpage, it can make use of this to render HTML. I imagine iOS uses something similar.
I believe this component is compiled separately for different versions of Android, and Android will only update to the newest compatible version.
Docs: https://developer.android.com/reference/android/webkit/WebVi...
Store page: https://play.google.com/store/apps/details?id=com.google.and...
Unfortunately, Microsoft signed a consent decree with the DoJ in 1995 which allowed them to add features to the operating system but meant they couldn't tie a separate program to the operating system. Therefore the browser had to be an added feature.
This was only a tiny part of a much broader decree. None the less, you can thank Janet Reno and the US government for the problems this has caused ever since ;-)
Use a consistent API and just upgrade the rendering engine, while maintaining quirks mode. It's not as much of a problem anymore because HTML5 specifies consistent parsing and rendering behavior for new and old documents.
