I can't see the use for this but I'd rather see it as an external recipe rather than a built-in new handler which would need to be maintained. Don't we already have popargs that could achieve such feature?
This is a better form of popargs, essentially. The main problem with popargs is that assigning _cp_dispatch is ugly and pretty unintuitive unless you're fairly intimate with CherryPy's workings. If I had of thought about it a bit more before implementing popargs, a SegmentHandler class that wraps an application class is what should have happened in the first place. That's the motivation here. It's a more user friendly way of supporting routed application code with object ids internal to the path.
I can appreciate that and I quite agree with you that popargs is not as intuitive as it should be. Yet I'm not at ease to add one more way of doing things. Perhaps for a future CP version where we make it leaner and drop some features in favor of others?
I'm not opposed to that approach, though I will say that it often is better to deprecate features by implementing the new, preferred method, and referring users to that approach, while supporting both for a limited time. I do understand your hesitation though. The way I see it, the code that this depends on (as well as popargs) hasn't changed in eons, and I wouldn't expect it to change anytime soon. I think it might be worth considering this a little longer, particularly how it plays with CherryPy's goals (which I'm fairly certain you have a better idea of than me, but API friendliness, simplicity, and "pythonic" / object approaches come to mind).
Either way though. I think this design pattern in general (object ids internal to a URL) is pretty common, and I just want CherryPy to support that pattern in a sensible manner.