Wrapping `Record` in `Foobar` or `BazQux` is just not a good pattern, even if it's common place and is included in current guidelines. Most of the time, you don't have gems that would use the same class and thus would rather not type a long name-spaced name every time you want to use `Record`. But when you do have gems with conflicting classes, you'd have the power to wrap one of them or both in a short namespace identifier and be in charge of the naming. Using modules for wrapping is a pattern currently, but modules should primarily be used for mixins, not name-spacing.

If you don't have a conflict, and the module is wrapping everything, nothing stops you from doing "include <yourmodule>".

Similarly, if you want to group modules that don't conflict together under a short module name, nothing stops you from doing:

    module MyGroup
      include Module1
      include Module2
      ...
    end

In other words, wrapping them doesn't remove your ability to use short non-namespaced names.

Using `include` of specific functionality into a class that will use it is furthermore an idiomatic way of avoiding that extra typing without polluting the global namespace

For that matter, you can often achieve close to what you're arguing for as well without actually making any changes to Ruby:

   def wrap_load(path) = class_eval(File.read(path), path)

   module Test
     # some_file.rb will act as-if defined within Test
     wrap_load("./some_file.rb")
   end

You can do better than that, to get closer to emulate `require` rather than `load`, and handle dependencies.

Overall, I think the fact you can do these things suggests you could probably write a good enough plug-in `require` monkeypatch suitable for the rare cases where `include` from within a class or module without needing a language extension.

What's the difference between FooBar::Record and ns1::Record? Nothing, except the latter pushes encapsulation onto the user.

This is not the Ruby ethos.

Realistically it would be FooBar::Record and ns1::FooBar::Record too, unless gems start replacing their top level module FooBar with FooBar = Namespace.new.

And why would you bother doing that when it would be a breaking change?

On a purely syntactic level snake_case gives me a clear indication this is something different (not a module). But the underlying mechanics of how namespaces would work, as I've mentioned in another comment, is that the choice of picking namespace identifiers is shifted to users of gems/libraries. I think the proposal might further benefit from maybe giving libraries default namespaces and, for example, Go does exactly this: you can import a package with the namespace prefix defined by package author, but you can also change it or import it without a namespace prefix at all.