This could be solved by having (internally) a map of { path: [handler 1, handler 2]}. That makes static path matching constant time, and static paths with multi

This could be solved by having (internally) a map of { path: [handler 1, handler 2]}. That makes static path matching constant time, and static paths with multiple handlers iterate over the requests appropriately. This can be a little confusing, especially given that you'd be specifying static and non-static paths separately, but it could be argued that that is less confusing than some methods. For example, nginx's method allows you to define paths in any order, but checks routes matching regular expressions first in config order, then picks a static route by most specific match; IOW the order of your routes in nginx doesn't matter until you have regular expressions, in which case it is surprisingly critical some of the time and irrelevant the rest of the time. Breaking it up into 'regular expression routes (checked first)' and 'static routes (checked last)' could simplify things conceptually, but doubtlessly raises more usability issues as well.