It should be a complete no-op, as it does not touch any runtime code, only types.

Well, you're adding some open Misc in places. I'll agree that it probably doesn't change anything. But it's not obvious.

Btw, I don't like this PR: I'm against "transparent" type aliases, they are arguably nicer to read, but they don't really bring you any extra safety and the added information is only available at the declaration, not when used.
I'd rather see labels added to functions, exception/constructors defined using inline records, than having them declared using type aliases.
Another option would of course be to use abstract types (which would be aliases under the hood, I'm fine with that), but that's a lot more heavy weight.

That's of course only my personal opinion and I'd be curious to hear what you and/or other people think.

I think that transparent type aliases definitely improve the situation, because they make declarations readable -- in many cases they were not before. I could not go on with my refactorings without them. If you do believe they are a strict improvement, then I think you could approve the PR.

What you have in mind is indeed better, but it makes changes much more invasive as all use-sites have to be changed. It would be nice work to do, but these changes are not the focus of my work, just side-works, so I don't want to spend a lot more effort on them for now. Anyone is free to come after this change and use type modname = Modname of string [@@unboxed] -- it is much easier to do after this PR. But I don't think the two steps of changes should be required to happen at the same time.

It's not a panacea, but there's indeed some added value in this PR.
The aliases do not enforce anything statically, but they at least document informally what these string types stand for. I think that information is always good to have; it would be disappointing to not integrate it and continue having everyone re-doing the job of inferring it from the code.

I'm against "transparent" type aliases, they are arguably nicer to read, but they don't really bring you any extra safety

The advantage compared to the current situation is clear ("nicer to read") and I don't see any disadvantage. In particular, this PR does not make it more difficult to evolve to something that would bring more safety (quite the opposite actually). The only risk is that a wrong annotation could indeed be misleading, but I trust @gasche was careful enough. So count me in favor.

Ack. I'm not planning to veto that PR anyway.
I was just saying that:

The aliases do not enforce anything statically, but they at least document informally what these string types stand for.

doesn't convince me. A docstring would have done just as well.

I tend to agree with @trefis in this case, but I still think that this PR goes in the right direction. I'm not fond of putting things in Misc though.

I'm pretty sure making crcs abstract would have very little cost. IIRC, it's only really used in Consistbl, and could live there directly. That would be a nice change to do later.

I fixed check-typo but Changes, for some reason, still complains. Merging nonetheless to encourage people to look at #2228.