Is there a way to "tag" a key in a way that prevents it from being reused?

Say I have a pair of public and private keys associated with some resource (e.g. a TLS certificate for a website mycoolsite.com). I am free to take those keys and reuse them for a different resource (e.g. for anotherneatsite.net). My question is: is there an efficient way to "tag" the original keys with the data "this key is for mycoolsite.com" such that removing the tag would invalidate the keys?

The idea would be to allow an authentication system to reject a public key if it were reused for a different account. To be clear, this is a general question about public key encryption systems, not just TLS.

My question is: is there an efficient way to "tag" the original keys with the data "this key is for mycoolsite.com" such that removing the tag would invalidate the keys?

Yes, that's basically what certificates do, where you can have a domain name in the X500-style RDN (Relative Distinguished Name). It is also possible to have (critical) extensions that contain additional data such as the subject alternative name or key usage. "Critical" means that the extension should not be ignored even if the extension is unknown. All this data is signed by the CA issuing the certificate and MUST be validated by a verifier.

Of course, even a MUST within a certificate verification procedure can be ignored. It is not possible to invalidate the key itself, and you cannot force a system to ignore data sent to it from the outside (unless you sandbox the system I suppose).

Nor is it possible to disallow the user to copy the public key or to request a certificate somewhere else. Sometimes specific CA's will keep an ID of the keys within the certificates they have signed. In that case a CA could choose to ignore a certificate request with an "old" key - although in my experience this is more about avoiding errors within the system.

And finally, it is not possible to restrict the use of a private key. The holder of an RSA private key could use that key for signing or for key establishment, even if the certificate information states otherwise. The certificate just states what the key pair can be used for, but it is up to the party that receives, validates and trusts the certificate to enforce this.

One way is this:

1. Client generates private & public key.
2. Client sends public key to server.
3. Server generates a derived key from the client's public key and a random nonce.
4. Server sends the nonce back to client, who can use it to create a derived private key.

In this way both client and server contribute randomness to the key, so the client cannot choose a poor quality or reused key by itself. At the same time, the server never knows the private key.

How to perform step 3 depends on the algorithm used. There are some examples in answers to this question.