New router DSL doesn't propagate requirements to nested resources

Given a top-level resource like this:

resources :articles, :id => /[^\/]+/ , :path => 'wiki'

In other words, an ArticlesController, available at "/wiki", and with pretty much anything except slash allowed in the :id so that we can have wiki article URLs like "/wiki/Rails_3.0_update_notes" (ie. without the period being treated as a format separator).

Now let's add a nested resource. In beta 4 this worked:

resources :articles, :id => /[^\/]+/ , :path => 'wiki' do
  resources :comments, :only => [ :create, :new ]
end

In the RC, any route involving a period in the article name yields a "No route matches" exception. e.g. "/wiki/some_article/comments/new" works fine, but "/wiki/Rails_3.0_update_notes/comments/new" raises the exception.

The workaround is to explicitly repeat the requirements in the nested resource like this:

resources :articles, :id => /[^\/]+/ , :path => 'wiki' do
  resources :comments, :article_id => /[^\/]+/, :only => [ :create, :new ]
end

Wondering if this is an unintended regression? Back under Rails 2.3 and the old router DSL I also found that I had to repeat the requirements on the nested resource in order to prevent the period from being interpreted as a format separator:

map.resources :articles,
              :as => :wiki,
              :requirements => { :id => /[^\/]+/ } do |articles|
  articles.resources :comments, :requirements => { :article_id => /[^\/]+/ }
end

When I switched to Rails 3 I noticed that I no longer needed to explicitly propagate those requirements, but now under the RC, I do again. So is this an unintended regression?