“either, but only the case of UAs that do not already implement same origin requirements or are not otherwise mandated to do so (e.g., mandated by HTML5); we want existing HTML4/XHTML1 category UAs that do not otherwise implement same origin to be able to normatively make use of css3-fonts and woff without bringing same origin into the picture;”
So you explicitly want the same content to look different based on whether the UA understands only HTML4/XHTML or HTML5. No wonder this is so hard: the feature you’re asking for is most definitely a bug to the rest of us ☺
“maintaining interoperability while permitting forward compatibility with HTML4/XHTML1 class UAs or any similar UA that does not already implement same origin restrictions;”
No compatibility is lost. To use your terminology, the ‘HTML4’ UAs can load any font the ‘HTML5’ UAs can load. They can also load fonts the HTML5 UAs will not load by default. Not only are they able to load all existing content but they will be able to load all content designed for the newer ‘HTML5’ UAs. This can be verified today since UAs are available in both categories. A UA that does not do any origin checks will, by definition, load font resources wherever they are located. Is this confusing ?
What is of course not maintained is conformance. If that is the problem then the bad news is that from a W3C standpoint your bug is – again - a core feature of the process. Drafts must be able to break conformance with a previous draft. As Liam pointed out, you can only maintain conformance with a REC, not a draft. Until there is a REC you’re not confirming with anything.
“the desire to avoid introducing an asymmetry in css derived resource fetch processing, namely, where same origin applies only to fonts but to no other css derived fetch”
Can you elaborate on why this is a problem in practice ? Specific examples and use-cases demonstrating actual harm would be very helpful.