Make the inverse of Onion-Location
Onion-Location asserts that an onion host is an accepted alternate host of a clearnet DNS host. But its assertion is trustworthy only if the clearnet host that makes the assertion is trustworthy, for instance if the clearnet's encryption certificate was established before the onion. The Onion-Location header asserts in only one direction: clearnet authorizes onion.
But consider the inverse situation: an onion host that is more trustworthy than a clearnet host that asserts via Onion-Location that the two are associated. The clearnet host could simply mirror the onion's content and look like it but not be authorized by the onion host. To verify that a more trusted onion host authorizes a less trusted clearnet site, the onion host would have to assert that it authorizes the clearnet host, for instance via a header that is the inverse of Onion-Location, sent by the onion host and pointing to the clearnet host. That would assert in the other direction: onion authorizes clearnet.
Another method to assert in both directions is to include both hostnames in a TLS certificate that both hosts use. But there is not yet a certificate authority that issues these let alone one that issues DV certs for an onion for free, and it would nudge onion services to depend on the CA hierarchy and depend on it not for the primary purpose of a TLS certificate to encrypt connections but simply for the purposes of authorizing the other host and/or authenticating themselves (AKA signing).
It can be done without DV certs for onions by signing a statement containing both locations by the private key of the other host. Along with (X)-Locations, include the signature by the other host and its public key/cert to verify the signature.
Example: example.com sends a header containing a statement of both locations signed by the private key of example.onion and sends the public key of example.onion. The browser verifies the signature, verifies that the public key it received is identical to the onion domain in the statement, and verifies that the tab's URL matches the .com (Clearnet|DNS|Alt)-Location in the statement. If the onion domain is a hosting service whose accounts are on subdomains or directories, the comparison of the public key may have to be on the level of the host or the page and could not be made unless the browser navigates to the Onion-Location. Onion keys are only at the domain level as far as I understand, so that use case may not be supported adequately for some people.
In the inverse situation, example.onion sends a header containing a statement of both locations signed by the private key/cert of example.com and sends the public key/cert of example.com. The browser verifies the signature, verifies the cert's CA chain, and verifies that the tab's URL matches the Onion-Location in the statement. Like in the other situation, the cert may have been issued for the domain or the host or a wildcard which may be problematic.
Optionally, instead of the statement being signed by only the other host, it could have two signatures, one from each host. That way, the whole package -- statement, signatures, and public keys -- could be copied identically to both hosts and save the administrator some headache.
I guess this is a draft of a proposal or RFC.
This could allow other features such as context menu buttons to choose between "Copy Link Onion Location" and "Copy Link (Clearnet|DNS|Alt) Location" on the current page. Further, it may be able to allow something like seamless browsing on the onion while the address bar and relative anchors display the location preferred by the administrator. That would be similar to one of the advantages of the Alt-Svc header.