It wasn't clear to me where you'd got this from, so I went to look at stable-maps. At least as I understand it, if we were to give StableName a phantom role, that would break System.Mem.Stable.Map because you could coerce a StableName a into a StableName b, look it up in the map and thereby coerce an arbitrary a into b.

I think the comment above could be reworded to be more clear. It's not obvious to me whether you're saying the property holds, or should hold, or should not hold, or what "pulling tricks" means. Could you say precisely what will go wrong if we use a phantom role?

I'd actually be tempted to consider using a phantom role and forcing stable-maps to wrap the StableName type.

So if we have this, can't you use it to break stable-maps?

you could coerce a StableName a into a StableName b, look it up in the map and thereby coerce an arbitrary a into b.

That is precisely the potential problem. I believe the property currently holds. "Pulling tricks" means using something like unsafeCoerce.

I'd actually be tempted to consider using a phantom role and forcing stable-maps to wrap the StableName type.

That sounds like it would require input from the community. If we're going to think about breaking things, I'd much rather break things better:

1. Change the kind of StableName# so it doesn't have a parameter at all.
2. Add a StableName_ (or whatever) type as a thin wrapper: data StableName_ = StableName_ StableName#.
3. Make StableName itself a compatibility wrapper around StableName_ and expose its constructor from an internal module.

Definitely. But you have to import an unsafe module and do it on purpose.

I actually just realized that what stable-maps is doing is pretty badly wrong anyway. The invariant I thought we had is not really there. See the ticket. Perhaps a phantom role for StableName isn't so bad after all, if we can't safely use a representational one.