This is an interesting problem, and not one I personally had considered. The behavior is by-design as I'll explain in a bit. The closest alternative you can consider is using site-level isolated storage instead of application-level isolated storage. However:
1. If SLS's subdomain is variable too (e.g. your app is occasionally served from msbluelight-1.agappdom.net instead of msbluelight-0.agappdom.net), then you still have the same problem.
2. Other apps on the same subdomain will have access to the data you stored in your isolated store.
To give you a little more background, consider some of the following scenarios:
1. A page contains two Silverlight apps, a main app and an advertisement (probably served from some other domain). The ad really shouldn't have access to the main app's isolated store.
2. Two websites running on the same domain, e.g. user1.asp.net and user2.asp.net or asp.net/user1 and asp.net/user2. For security reasons it's important that both users can be guaranteed that their isolated store can only be accessed by themselves.
3. Two applications running in a single site want to share data, e.g. asp.net/forums and asp.net/contact may both want to access the same isolated store.
We addressed these 3 scenarios using the design we have today: each XAP gets its own isolated store (based on its URL) and each XAP gets access to a shared isolated store (sharing occurs at the subdomain level).
I'm not sure I see how we could preserve the scenarios above while also supporting yours. If we allowed a page to specify an identity of isolated storage, then nothing would prevent a XAP on asp.net/user1 to use an identity used by asp.net/user2.
Does that make sense?
I wonder if perhaps you should consider storing the data on a server. Not sure if you can do that with SLS, and not sure if you'd want to store it on your own server either.
- Wilco Bauwer (MSFT) / http://www.wilcob.com
