After reading the ws-routing specification, it appears to me that people will interpret the composition of a SOAP Router in very different ways. The specification requires the implementations to conform to a minimal amount but also encourages alternative uses. Additional functionality that may be included in a SOAP Router that are beyond the ws-routing scope include: message filtering, message transformations, content based routing, load balancing, response-message caching and others. Actually, the inverse is more likely to happen: participants in an SOA will incorporate routing functionality (e.g. SOAP Load Balancers will incorporate routing functionality, etc.)
The 'good side' of this is that people will create new servers (like content based routers) that are single-purpose utilities and leverage the basic infrastructure of the ws-routing specification. The ability to drop routing functionality into the server facilitates the pipeline service pattern. This, in my humble opinion, is where the magic of a service oriented architecture is created.
There are a few potential downsides to not having an actual specification for a SOAP Router. One is that many of the functions that a router can perform are very dissimilar (domain routing vs. content routing). By keeping a server homogenous, you are able to more accurately predict the response to changes in the router settings (e.g. routing logic based on complicated algorithms, etc.) Also, from a marketplace perspective, it is hard to comparison shop for a 'SOAP Router' when the functionality can swing so drastically - although, one could argue that this is what slow down product commoditization.
Either way, when vendors begin releasing SOAP Routers, it may be worth asking, "So, what exactly does your router do?" And perhaps one day, the WS-I or another organization (the ws-duopoly) will create a SOAP Router Profile.