This is not a problem with your patch proper, but: it is hard for newcomers to figure out what's going on here, because you carved out a nice API to talk about "preparation" (before prepare_for_printing and then prepared_type_expr, and now your masterfully named add_type_to_preparation), but the code of typeclass.ml is not using it consistently.
It prepares but never uses prepared_type_expr. Most of the printing calls weirdly use the lower-level function Printtype.tree_of_typexp, which of course does not specify whether it resets the printing context or not (and good luck figuring out from the implementation), they should be refactored to use prepared_type_expr instead. Then the Unexpected_field case calls Printtyp.typ_expr, which I think is a small bug (the prepare_printing call above is probably a no-op?

While we are at it, on the preparation API:

• I think it would be more natural (and would require less masterful naming) if prepare_* would always add a type to a current preparation. That would require having an explicit reset first (or, if we prefer, start_preparation), and we should ensure that the following printing always uses a prepared_* function.
• We could detect this kind of bugs if we temporarily (to run the testsuite for example) made it an error to reset the context before printing prepared expression. This could be done by incrementing a counter on prepare_* calls, resetting it to 0 on prepared_* printing calls, and emitting an error or warning if reset () is called while the counter is not 0.

Good catch on the redundant call to prepare_type in the Unexpected_field case.

The call to the low-level tree construction functions are currently necessary due to the fact that the printing type needs to go through two stages of preparation before any type is printed:

• First, loops are marked and type variables are named
• Second, types constructor are shortened and colliding identifiers names are annotated with the /$n suffix.

This second stage is done when constructing the outcome tree and relies on an internal mutable state. Consequently, all trees needs to be constructed before any of them are printed. One of the many advantages of #11515 is that it removes this internal state which means that it would be possible to remove most calls to the tree_of_* functions when printing errors. A temporary alternative would be to annotate paths within Printtyp.prepare_type, which is sufficient for removing at least the calls to Printtyp.tree_of_typexp.

In term of API, I think that my current opinion is that it would be better to materialize the existing mutable stables in the Printtyp API.

Hm, so i guess the short-term conclusion is that we should not try to use prepared_* everywhere for now but wait for #11515 to be reviewed and merged first. Makes sense to me.

I am planning to cherry-pick the change to 4.14 in order to have the fix available for merlin too (currently merlin loops with the new example in the testsuite).