I guess it's not the access control spec itself per se, as much as it is Firefox and Firebug's implementation of it. Though it is frustrating that a request from the http version of a site to the https version of a site is considered cross-domain; the domain name and thus the set of IP addresses used in each case is the same, so I don't see any scenario in which you could control one but not the other, at least, not one that would otherwise be winnable (e.g. malicious router on the backbone routing things at the application level - it could do that for different file paths within an application, let alone different protocols).
When a cross-domain XHR fails under Firefox, there's no feedback as to why. There's no exception, no console message. The Net panel shows the requests that have been made - so you might see the OPTIONS preflight request, if one is made - but it doesn't tell you if/when it's discarding the results of a request (in response to security policy bits not being satisfied), or why. All you get is an empty XHR object in an error state.
Which is... difficult... to debug.
My web hosting package allows you to serve content out of one directory on http:// and another on https:// (thankfully disabled by default), though even if one took advantage of that situation with malicious intent it's still a server-side issue, and I can't really see the point in trying to block that on the client.
This is my finding with Firefox in general; it's generally quite unhelpful when it comes to security problems in JavaScript. [sad] Good luck finding a solution!