I think we might prefer to do the opaque_identity earlier. Right now it is not a problem since Obj.tag is a C primitive, but we don't want this to break if this changes to be something that the compiler understand. If one of the previous if is decided statically, it will break badly.
This probably hint that we also want to add [@inline never] as inlining this function might is never beneficial.

That's what I did initially, but then I thought the other branches were pretty safe and we could benefit from the early cutting of branches if the tag is known. But I now remember that while it might be fine for the regular tags, it would be wrong for the forward tag. Would you accept a version where we first test for a regular tag, and in this case take the regular branch, otherwise wrap in opaque_identity then branch on either Lazy or Forward tag ?

Never mind, I've tried it and it's too much complexity for very little gain, I'll push the initial version back again.

I don't understand the problem in the other cases (I thought that the problem was having a (dead) branch that mutates a value that is known to be immutable, how do other branches lead to mutation?). Can you explain?

The last version I pushed includes a comment with more details, does that help ?

When I read this explanation, my reaction was that trying to fix the problem here was not such a good approach, instead we should make the construction of Forward_tag values opaque. In fact this is exactly what is done in #713. Are we sure there still is a problem here? When would the optimizer know that a value has a forward tag?

@chambart could you clarify what you meant earlier by "break badly" ?

I've discussed this with @chambart offline. To sum up, the problem is indeed that if the simplifier assumes that a block has tag Forward_tag, then it could remove all the other branches, but this would be wrong as the GC can shortcut the forward block and replace our value with one with a different tag.
The previous PR (#713) works around the problem by wrapping all occurrences of forward block creations in Popaque, which should prevent the optimiser from ever assuming a block has Forward_tag from its creation. Here we document that this is one place where this problem can occur, and the Sys.opaque_identity call provides an extra level of protection (There's nothing wrong with being more careful than necessary).
I also find it more satisfying to have opaque wrappers at both points, as at creation time it shows that the tag may change, and at the point where it's matched on it documents that this particular operation (reading the tag of the lazy block) is "volatile", meaning it has to operate on its actual argument and not on any approximation of it it has.
To give you one example where the optimizer might assume that the block has forward tag, imagine two calls to Lazy.force on the same value, but with some other code in the middle. The optimizer must not reuse the tag it got from the first call, because it could end up being outdated. The extra opaque_identity forces to reload the tag. (Currently Obj.get_tag is a C primitive so it cannot be shared or reused, but we consider it would make sense to turn it into a compiler primitive at some point and are not very keen on leaving this kinds of pitfalls wide open).

We also discussed adding an [@inline never] attribute in addition to the Sys.opaque_identity call, because the function has a non-trivial body that will not be simplified, so there's almost never any reason to even try to inline it and this can save (a little bit of) compilation time. I'm not completely convinced it's worth spending too much time on it, so for now the version with no attribute remains.