When not to use ACS?
You shouldn't use ACS as an identity provider.
Occasionally I see some confusion as to what role ACS serves. ACS at is core is a federation provider, but there is a valid scenario in which you want your backend service (a trusted subsystem) authenticating directly to ACS using a shared secret or a certificate. This can be done using Service Identities. However, more than once I've seen an ACS scenarios proposed where multiple accounts are to be provisioned, and this was going to be achieved by creating a service identity for each user.
That's really not how ACS is designed. If you suddently have thousands of users, making ACS your authoritative source user directory won't scale. ACS offers a nice rules engine that was designed for normalizing incoming claim types from various identity providers, or for simple authorization policy such as generating role claims.
But ACS' capabilities here should not be confused with fully powered directory, authentication and authorization solutions such as AD and ADFS. In short, ACS is not a could version of AD/ADFS.
Even though you can use Windows Live as identity provider in ACS, there are some cases where you would not want to use it. The user ID you receive depends on the ACS namespace. This means that if your application uses multiple ACS namepaces (lets say one for europe and one for USA) this might cause some issues.
Imagine the scenario where your user logs in through your USA namespace. Your application will receive the ID (hash) for that user and you'll maybe create a profile for that user in your application. A week later your user travels to europe and might log in through your europe namespace. Even though this is the same user, you'll get an other ID (hash) for that user, making it seem this is a new user, even though it's not. This is because the ID (hash) depends on the ACS namespace.
The user ID that you receive from ACS for Windows Live ID will be specific to that user at your service namespace. If you use a different service namespace, you'll get a different value for the same user. So to answer your questions: * Labs ACS and Prod ACS [Different IDs]
Different relying parties in different subscriptions (in prod) [Different IDs]
Different RPs in the same subscription [Same ID if the service namespace is the same, different for 2 namespaces in the same subscription]
If I delete and rebuild the RP to the same realm, same account [Same ID]
Update:
To reply on one of the comments, it's true that you won't get the email address from the Windows Live identity provider. But you should assume that you can't control the information you'll get from public identity providers. A good practice would be to simply depend on the identifier of the user and to create a profile for the user (you'll manage the profile in your application). When you get some information from the identity provider you can already update the profile, but if this info isn't available you should simply ask the user to update his/her profile. Be sure to look at the BlobShare example for more info.