I have reported this error before...and have a TAC case open for it...but have found a workaround that I wanted to share that might shed some light on the issue.
The URL of Common Services > Device Management when I get the error contains the FQDN.
If I modify this URL by removing the domain suffix and attempt the same change in the DCR the change is successful.
I found the problem. As I predicted, it has nothing to do with browser, FQDN, or anything. It is a transient issue that only affects Windows SMP systems. It tends to occur mostly on faster machines. A patch is on its way.
Local applications should never need to be registered. This happens at install time. If, however, you lose local applications (like Common Services) there is a command-line only procedure to get them all back. TAC needs to walk you through this, though.
I don't see how it's possible not to have applications which are installed on a server not available for remote registration. I certainly cannot reproduce that. You may very well have a problem with the CMIC registration database, and it might be a good idea to have TAC walk you through the procedure to dump and re-register all local applications on both servers.
No, the register from remote server works just fine with short hostnames. I'm using it that way in my lab. Everything comes done to the SSL cert. If you create the certs with short hostnames, then you register servers with each other using short hostnames, and you access servers using the short hostnames, then everything will work.
Alternatively, if all of this is done with FQDN, then FQDN should work.
You need to decide how you want this all to work, then start from scratch. Regenerate the SSL certs on each server using the proper hostname. Remove all accepted peer server certs from each server, then reimport the new certs using the proper hostnames. Finally, re-register the applications from remote servers using the proper hostnames, re-setup DCR integration using the proper hostnames, etc. and everything should just work.