Up to the couple of things I pointed out, the change does almost as advertised, the only exception being that the type extension_constructor is not aliased anywhere. Might be worth adding in Obj for consistency?
No strong opinion, but it could fine to alias all built-in type constructors in stdlib.mli, so that reading stdlib.mli tells you the initial scope. For this reason, I see no issue with having Stdlib.option and possibly in the future, Stdlib.Option.t.

I'll note that although this enable uses of the type constructors Stdlib.bool, the value constructors cannot be used in some cases, which theoretically limits what can be done without triggering warning 40 and 42 (which are enabled by default, even if I always disable them):

# type bla = [] | (::) | () | None | Some | false | true;;
type bla = [] | (::) | () | None | Some | false | true
# Stdlib.[];;
- : bla = [] (* wrong: scope issue *)
# let v = Stdlib.(false);;
val v : bool = Stdlib.false (* good, except the syntax "Stdlib.false" doesn't parse *)
# if true then false else Stdlib.(false);;
- : bla = false (* wrong: type based disambiguation apparently overrides module path *)
# if true then false else v;; (* good *)
Error: This expression has type bool but an expression was expected of type
         bla

And talking about constructors, the built in constructors of sum types are now available in the stdlib, but not the ones of exceptions (Not_found, Match_failure, Out_of_memory etc). I think you'd need to do this to claim to fix MPR#6655.

I'm not sure what you mean by "wrong" in some of the examples you list; do you mean that the current semantics is wrong, or that the behavior is too surprising and we should warn about it, or something else?

Note that

# Stdlib.[];;
- : bla = []

comes from the fact, I think, that Jeremy re-exports [] in Stdlib.List, not in Stdlib itself. Since 1c4ee3a, which was merged in 4.04,M.[] is resolved as let open M in [] (where [] is handled as an identifier "[]" by the parser).

Oh well I expected []/true/false to be normal constructors. But you're saying they are not, because there is no syntax to access a prefixed version of them, and the syntax that looks like that is actually a local open, so that explains the weird scoping.
Alright, well nevermind this remark.

Thanks for the thorough review, @sliquister. I've addressed your comments in the latest set of pushed commits.

A number of tests are currently failing due to changes in type printing. I plan to wait a little while for further comments on the existing change before addressing the tests to avoid churn.

the type extension_constructor is not aliased anywhere. Might be worth adding in Obj for consistency

Done.

And talking about constructors, the built in constructors of sum types are now available in the stdlib, but not the ones of exceptions (Not_found, Match_failure, Out_of_memory etc). I think you'd need to do this to claim to fix MPR#6655.

Done.

Another beneficial effect of this PR is that it solves the issue with the manual index MPR#7708 by giving an indexed path to built-in exceptions and types.

One thing I hadn't commented on is: I'm not super happy about the not-real-constructors [], (), true and false showing up in actual OCaml code. It is an open secret that these parse, and some people that are too clever for their own good have used it in the wild already, but having this right in Stdlib may hide the fact that this is an undocumented, not-guaranteed-to-keep-working thing the parser currently does.

Could you maybe add a comment whenever this happen, to indicate that this is a hack to give a path in Stdlib to those constants, but similar tricks are not meant to be used in user code?

@gasche

I'm not super happy about the not-real-constructors [], (), true and false showing up in actual OCaml code.
[...]
Could you maybe add a comment whenever this happen

I'm happy to add a comment for (), true and false. But [] is a real constructor nowadays, isn't it?

Not in my book (but I would be wrong if it was, for example, documented in the language reference); I thought of this PR more as an exercise in making compromises on the implementation details that helps advanced users that do not-really-supported things.

The manual has:

constr-decl:
(constr-name || '[]' || '(::)') [ 'of' constr-args ]

IMHO, if [] and :: are not documented nowadays, then it's a documentation failure, not an undocumented feature. The fact that we can redefine them is extremely useful in many cases.

If you feel like this should stay undocumented, but still want to fulfill the use case properly, you are welcome to champion the first commit in my patchset for infix constructors. :)

For the record, I am rather in favor of integrating (::) and your infix constructors in the language. My impression, however, was that there was no consensus on that, and that user-defined lists were more of a tolerated accident. I appear to be wrong, though, as [] and (::) are documented. Maybe I should ask around to know what people feel now.

I would be happy to resurrect my patchset (or even a subset of it) if you feel the weather is more favorable.

About the weird constructors: it's probably time to resume working on MPR#5936. Please have a look at the discussion there.

@alainfrisch: I've removed the bool, int, and option aliases from Stdlib, and added true and false to the Bool module.

@damiendoligez You expressed somewhere else your reluctance against adding more "toplevel" declarations to Stdlib. Can we argue that the components added here (types and exceptions) are already part of the "global scope" anyway and thus assume you are ok with those additions?

The code/documentation looks good, I think the only concern is whether the warning on Failure "int_of_string" and friends is broken.

This is now fixed, and I've rebased/squashed to clean up the history. I've also opened #2133 to make the @ocaml.warn_on_literal_pattern attribute more meaningful for multi-argument constructors and non-trivial patterns.

I think this is now ready for merge, if CI passes. A number of tests are failing, because of printing differences, like this:

-        val print : unit -> unit
+        val print : unit/1 -> Stdlib.unit

Suggestions on how best to address these failures are welcome. Some possibilities:

1. Update the tests to use -short-paths, so that Stdlib.unit is always replaced with unit
2. Add a Unit module and move the type alias there instead, so that the built-in type is not shadowed by default
3. Special-case Stdlib in type-printing code so that aliases are always resolved.

My preference is for 2, but I'm happy to hear arguments for other approaches.

Update: I moved unit and exn out of Stdlib into their own modules (Unit and Printexc respectively).

Thanks @yallop!

The module [Unit] needs to be exported in [stdlib.ml]