I've always thought that these addresses should have a different scheme, not a different TLD. For example, onion://aoeusnth instead of http://aoeusnth.onion
Is there any reason in particular why the TLD approach was settled upon instead of a scheme-based approach?
Well, there's nothing keeping a well-defined tor scheme from including the protocol information in it, is there? For example, I could imagine specifying a tor URI in my git config: onion:ssh:pcl@aoeusnth or onion:http:aoeusnth
Think of TOR as acting like a VPN or point-to-point tunnel. You can conceptually think of it as another network interface plugged into your network. The policy you choose what to route over it is your own. It doesn't affect how any other protocols function.
I can still access regular sites over TOR. I can also access regular websites over a VPN. openvpn+http:// isn't exactly useful either for the same reason.
And there are other special tld. Your multicast domain group (e.g. .local) is also special. Your dns resolver sees the TLD and resolves it specially. But once again, doing multicast DNS doesn't impact http, git, ssh, etc. So it be silly to have to write mdns+http://... as well.
And if you where to join them, then you have to describe what kind of behaviour should happen if, for example, on openvpn+http://foobar.tld you hit a hyperlink to http://baz.tld. Do I rewrite this to prepend openvpn+? Fail? etc.
Because you then would have to patch all your software to understand the scheme. Which might actually be a good idea from a security POV, but is harder.
Is there any reason in particular why the TLD approach was settled upon instead of a scheme-based approach?