(Also in reply to @gasche)
Some amount of “freezing” helps. Let me explain with an example: Haskell and Golang “freeze” you into a IO system. The advantage is that every library that performs IO can work with another. In Haskell every library that performs IO can work with another library that performs IO. Same with Golang.
In OCaml, we need to ask : Do you use Async, Lwt, blocking calls, now Eio etc? All mutually incompatible with another to a large extent. It splinters an already small ecosystem. By settling on way to perform IO Haskell/Golang bought themselves some future inflexibility but in the interim created a strong foundation where hundreds of libraries could flourish. Similarly some amount of “freezing” around typed representations will help by providing a basic foundation for debugging, serialization etc.
Sounds like Modular implicits is a very tough problem in OCaml, tougher in the face of things like abstract types. Modular implicits is in the future and who knows it may never arrive! Modular implicits could be OCaml’s Nuclear fusion! Always destined to be in the future 
! Runtime typed representations could solve much of the pain to just getting simple debug deriving working without modular implicits.
But this does not imply I’m advocating a half baked approach. refl for instance struck me as a nice library, lets see if it can meet the needs of a 80% of the cases! In fact, @gasche in one of the responses says the OCaml’s compiler follows the 80/20 principle – provides 80% of benefits with 20% of the complexity. Lets extend that to runtime typed representations! Lets deal with 80% of the use cases, provide then to everyone via the Stdlib ! Putting something in Stdlib does not prevent better alternatives that more sophisticated users can use. Vectors in OCaml is another sore point for me – OCaml should provide dynamically sized arrays in its stdlib but does not yet. Hopefully PR can reach some consensus soon !
@dbuenzli has strong feelings on this and would like more primitives to be provided as far as runtime typed representations go rather than one blessed library! I’m OK with that too! Something, anything !
TL;DR: The lack of being able to simply derive a pretty printer for a data structures is huge gap. Automatic derivation via Modular implicits is the principled way to implement this no one knows when OCaml will get modular implicits. Failing this, we have the runtime type representation route – it locks you in to a specific approach (like Marshalling in OCaml does as correctly mentioned above) but it does not deeply have to affect the language itself. It would be in stdlib – most people would use it, people who didn’t want it could build their own.