One possible alternative might be to add the ability for user configuration to substitute one certificate for another one (both will need the same public key and subject name, but the substitute will not be self-signed (since you do not have the private key)), and to use the data in the substitute certificate instead of the original. If the name constraints extension is implemented, then it would make this and other things possible. Since the substitute certificate will be considered trusted, it is not necessary for the substitute certificate to have a signature (if it does (e.g. because you got it from somewhere else instead of making it yourself), then the signature can be ignored), nor is it necessary for the substitute certificate to be issued by anyone (this applies even if it is the end certificate being substituted).

I think some servers do not send a copy of the root certificate to the client. In this case, what I described above might already be possible even if that feature has not already been added to existing implementations, as long as it does not require the installed certificate to be self-signed.