Yes, someone could fork Gecko + XULrunner + Firefox; but it is a huge pain-in-the-ass to even track it as upstream, much less diverge from it.
It's purposefully architected to make a plugin very unsavory — you could do it with a plugin/extension that inspected every DOM for failed <video> embeds, dynamically replacing them with an <embed> of its own NSAPI plugin. You'd be guaranteed to get FOUC, poor detectablity, and regular breakage. At that point the author is better off just seamlessly falling back to Flash.
"It's purposefully architected to make a plugin very unsavory"
I'd like a citation for this please, or at least some synthesis based on some explicit rationale (which is what I expected on the with that em dash, instead of a non-sequitur).
Gecko links directly with liboggplay to restrict themselves to exclusively WAV and vorbis+theora in ogg containers. Every other app out there uses a standard media handling library: ffmpeg (esp. if bundling), GStreamer, QuickTime, DirectShow, or some combination of them.
This was made explicit when us proles discovered that Mozilla has had a GStreamer <video> implementation for two years, for use in their mobile port so that they have a hope of playing video in real time:
> My exclusive focus for this GStreamer integration has been to make it work with Fennec. Not enabling it in Firefox on platforms where GStreamer has been ported to, is as far as I know a political decision.https://bugzilla.mozilla.org/show_bug.cgi?id=422540#c105
Architecting against plugins is not new in the free software community. RMS purposefully designed GCC so that you couldn't interface with its internal representations to make it impossible to have independent language frontends, optimizers, or target backends. That led directly to ECGS, a complete fork of GCC away from the FSF's control after they let it languish and refused patches — the FSF lost and eventually blessed it as the 'real' GCC. Its closed architecture is the primary motive behind LLVM's ascendancy.
It's purposefully architected to make a plugin very unsavory — you could do it with a plugin/extension that inspected every DOM for failed <video> embeds, dynamically replacing them with an <embed> of its own NSAPI plugin. You'd be guaranteed to get FOUC, poor detectablity, and regular breakage. At that point the author is better off just seamlessly falling back to Flash.