What about rather following what is being proposed upstream. That way, in a few years, you can likely simply delete the code. In other words:

module Char : sig 
  include Stdlib.Char
  module Ascii : sig 
    val is_white : char -> bool
  end
end

I knew about the PR but I didn't use the same interface at the time for several reasons:

• the two definitions are different (e.g. \v and \f are not handled by the opam definition but are with the stdlib one)
• it wasn't merged at the time and we have a dedicated module for compatibility functions (https://github.com/ocaml/opam/blob/master/src/core/opamCompat.ml) so it would've felt a bit weird to have a yet-to-be-part-of-the-stdlib function in it
• OpamStd isn't meant to be a mirror of the stdlib in terms of naming, OpamCompat is

Now that it has been merged i can think about it again although i personally feel like it would be better to wait for the release of 5.4 to change the function. In the meantime i'm happy to add a TODO comment to remind ourselves to change it when 5.4 is released.

The new module should be in its own commit.

I prefer having both usage and definition in the same commit

Is there a reason to add a new module instead of adding it in OpamStd?

In my opinion OpamStd should only be an overlay over the standard library, a Cmd module doesn't fit that. Also the definition is big enough to warrant its own module, and in the future i'd also like to add more functions to this module like to_string.