I've never looked at it as a feature per se. The fact is, one can define whatever regular expression they like for their mapping, and this is simply a matter of handling that appropriately. If a regular expression doesn't match up to the end of PATH_INFO, or a forward slash, then what do we do in that scenario? Do we impose a limitation and say that a match must always end at a forward slash?  In an earlier version of Scorched, a forward slash was always inserted at the beginning of the unmatched path if one was not present, but this is merely because I had (unconsciously) assumed a match would always end at a forward-slash.

I'm sure there are use cases for URL structures that for some reason don't use a forward slash to separate out two routes or sub-controllers, like maybe the URL's '/article-2563' and '/post-2134'; maybe these are legacy URL's that need to be supported, who knows. I don't want to make assumptions and impose limitations for no good reason.

As for your example with `/auth` and `/authorities`, it's a matter of ensuring your mappings are defined in the right-order, or to otherwise ensure appropriate priorities are set. Sure, if we made the rule that all matches must end at a forward slash, or otherwise the end of PATH_INFO, it would not cause such a scenario, but then it's not without introducing the potential for a difficult-to-workaround problem, like in the case of supporting those poorly-designed legacy URL's.