It's possible to use invalid opam package names for dune package names in general (e.g. foo.0.1). When interoperating with opam we enforce opam's package naming rules but this is done inconsistently in our package management code as not all operations need to call into opam. It would be a more consistent user experience if all package management related operations require that package names be compatible with opam. The type Dune_lang.Package_name.Opam_compatible.t requires that the name be opam-compatible when values are constructed, so I think this is the type we should use to represent package names rather than the Dune_lang.Package_name.t type we currently use which doesn't require opam-compatibility.