> But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'?

This sounds like something that should be a feature of the protocol used for streaming (in fact, I'd be surprised if most streaming protocols didn't support such functionality). Even without, this should be possible to do even with a native media player, and many streaming providers offer streams with different bitrates and encodings and such (for an example, check out soma.fm).

> YouTube-like annotations?

Most video players have subtitle and even captioning support; it shouldn't be hard to extend this to arbitrary annotations, be it as part of the streaming protocol, part of the media encoding, or even as a separate stream or file.

> Show suggested videos after?

Could be hypothetically done with an API call on the player's part to the video source (or some other source that indexes videos), which then provides the list. The player could then display said suggestions.

All three of these things could be worked around with a standard "metadata" path that such a video player would access and fetch an HTML page or JSON/XML document or somesuch.

> Developers aren't going to want to support all environment configurations

Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0. I don't use separate web browsers for different websites, after all.

> Additionally, there's a lot of great research going into browser sandboxing and user-driven permission granting. Allowing content-compatible-but-unsandboxed XYZPlayer to take over content playback negates a lot of the potential benefits.

Part of the issue is that operating-system-level sandboxing has historically been insufficient. Bringing some modern server-grade sandboxing techniques (containers, VMs, chroots, etc.) to the desktop and mobile realms in an easy-to-use manner would alleviate the need for browsers to try and implement this themselves.

I agree that those are all methods of solving each issue -- but I think expecting each player to implement them (and correctly!) is the real problem. And when the standards don't support the feature they want, many developers would fall back to the web. It's hard to compete with a full-featured layout, style, and scripting implementation when it comes to customization.

Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0.

There are web standards now, but, in practice, when you're supporting multiple environments, you're also testing against them. For webapps, fortunately, this usually just entails testing the top 5 browsers for a few versions, and mobile devices if you support them.

If the user comes to support saying something is broken with the video on their native app, trying to troubleshoot their native environment can be difficult, and telling them that their environment might be configured wrong often doesn't solve their problem. Which is why I suspect each site would support specific players.. not being a real improvement over the Gecko or WebKit <video>, <audio> in my mind..