Still trying to wrap my brain around this but wanted to get an issue going for feedback, particularly from @zzak since he rewrote Sinatra::Namespace for 2.0 and is hopefully familiar with its inner-workings. 😄

Take the following sample application:

require 'sinatra/base'
require 'sinatra/namespace'

class MyApp < Sinatra::Base
  register Sinatra::Namespace

  helpers do
    def dump_args(*args)
      args.inspect
    end
  end

  namespace '/foo' do
    helpers do
      def dump_args(*args)
        super(:foo, *args)
      end
    end

    get '' do
      "#{dump_args}\n"
    end
  end

  namespace '/foo-bar' do
    helpers do
      def dump_args(*args)
        super(:foo_bar, *args)
      end
    end

    get '' do
      "#{dump_args}\n"
    end
  end

  run! if $0 == __FILE__
end

Expected output:

$ curl localhost:4567/foo
[:foo]
$ curl localhost:4567/foo-bar
[:foo_bar]

Summary: The super of each namespace's dump_args helper is expected to be the dump_args helper defined in the parent application.

Actual output:

$ curl localhost:4567/foo
[:foo]
$ curl localhost:4567/foo-bar
[:foo, :foo_bar]

Summary: The super of the second namespace's dump_args helper is the dump_args helper defined in the first namespace.

Although the two routes are in two separate namespaces, and hence, ostensibly, in two separate modules, it appears as though the latter is nested under the former. This only happens when the longer route starts with the same string as the shorter route; i.e. if the second namespace were named simply /bar, this issue would not manifest.

I can confirm this issue is present in Sinatra 1.4.8 (with and without Mustermann), 2.0.0.beta2, and master tip.