We agree on a) and b) and the current implementation clearly follows this.
In the current implementation of the routebox component, there is only one inner context created for a unique endpoint name. The endpoint name is then tied uniquely to its innerContext and host multiple inner routes. This should meet your requirement relating to encapsulation, hosting and strategy/map based payload indirection to inner routes.
As for point c) in your comment, the URI definition is where the divergence with your requirement is indeed present and I am aware of this.
My design/implementation choices were guided by the following reasoning given below
Currently in Camel, Protocols/URI schemes enable binding & registration of a specific component known to the Camel Context which is then used as a factory to create specialized endpoints of a given type (e.g http, jms etc). The protocol/URI scheme mapping to a component registration is done at context creation automatically using an API called addComponent(String componentName, final Component component) .The only exception is when a routebuilder is used to add a component.
Therefore, you will find that when you add a camel component maven dependency in your pom file the component is automatically registered under its fixed name. This happens via a file which is scanned during context creation and is present for every component in .../trunk/components/camel-routebox/src/main/resources/META-INF/services/org/apache/camel/component/routebox which contains a single entry for its associated component. The name of the file (routebox) is wired to the URI scheme and the component associated is added to the component list. Following this, camel now has the ability to create the requisite endpoints.
Now coming to the answer you are looking for... The reason James talked about a ProtocolBuilder akin to a RouteBuilder was so that this magic of mapping "bookstore" to the Routebox component could be performed by the API which the user could write code for (or maybe not, based on the design)... This addComponent() would need to be done every protocol (bookstore, bookstore1, mybookstore etc) you were planning to use.
Also, since the URI scheme suddenly became cheap, you could add all manner of names for components and potentially override the values of well known protocols. You could run into name clashes in different ProtocolBuilders trying to do the same thing.
RouteBuilders currently can do the same for you. You can add a line to your configure method to do an addComponent("bookstore", RouteComponent")
I decided not to pursue this road since RouteBuilders currently can do the same for you and the ProtocolBuilder was in my view over-engineering for little gain. You can add a line to your configure method to do an addComponent("bookstore", RouteComponent") even now and then do a
with an exchange header ROUTE_DISPATCH_KEY=addToCatalog so the payload can be indirected to URI seda:addToCatalog.
BTW, I spoke to James and Claus a few weeks ago in early December about my design and implementation strategy. I also rotated this many times in my own mind, ran these ideas by an existing customer with similar needs regarding pros/cons and arrived at this point. James did think that my design was proper (though not how he had envisioned it in the beginning) and asked me to go ahead and contribute the code as seen in my current implementation. I also spoke to Claus briefly and he was quite happy with the implementation plan.
I am not saying this is the final form for this component. I am happy to take on any thoughts, ideas and/or patches you may have and re-factor the component appropriately.
Sorry about the rather long winded answer. I hope this given you a sense of where I am coming from.