“We absolutely, most certainly, should NOT ship libraries with operating systems.”

It could be a 'use the default or link your own' situation, which then wouldn't influence a whole lot.

But I agree, overall.

I think the direction of the influence would mostly works the other way round. If there's an attribute on the HTML link tag that some browsers recognise as calling the browser's client-side version of that library (with local/CDN fallback for browsers that don't) then users are going to notice that browser X seems to load a lot of websites more quickly than browser Y, which puts pressure on the vendor of browser Y to make sure it also supports these frequently-used js libraries (especially if they're large frequently-used libraries with multiple minor version numbers and no widely-accepted-as-canonical CDN source)

This is still a shame if you're maintaining a heavyweight alternative to jQuery or React which is far too obscure to be a consideration for browser vendors, but it's a big boon for users, especially users on slow or metered connections that download several different version numbers of jQuery from several different CDNs every day.

I'm not sure that is true. No one is saying external libraries cannot be loaded. It is actually a good idea to be able to rely on certain popular libraries already on the client; this makes a lot of sense. You can still have the existing mechanism so I don't think browser vendor are going to hold everyone hostage.

If you like, there could be mutually agreed upon standard repository that browser vendors routinely update from.

Sure, your less popular experimental library won't be in the list, that's what "<script src=..." is for.

It probably won't happen but it is hard to defend the position that it is a bad idea, I think.