Interesting thought, but the static XHTML pages that are produced don't necessarily come from the cart itself.
Allow me to demonstrate:
http://www.hibiscusflorals.com
If you go through the site, there are various product pages that have non-dynamic extensions.
But...none of those pages exist.
For example:
http://www.hibiscusflorals.com/silk_...dding_packages
Is not a page anywhere on the site.
Confused? Hopefully I can explain this in a way that makes some sense.
As I stated before, the page above does not exist. However, it has a category name of "silk flower wedding packages". I've created a custom 404 (default page used to handle "page not found" errors) that checks the URL, sees if there's something that's supposed to match it (in this case, silk flower wedding packages) and display that in its place.
Neither the user nor an SE would know unless I told them, and both the user and the SE get the same experience.
In other words, the cart itself doesn't handle the SEO...the developer, via customization and/or application, does.
Note: the cart above has recently been tweaked so that duplicate category and product URLs are going to be merged, so right now the full SEO effect cannot be determined (Google thinks
www.domain.com/ABC.html is different than
www.domain.com/abc.html .)
So...Google, Yahoo!, MSN et all aren't going to sell you what you want, simply because it's already incorporated functionality within most servers...it just has to be accessed.
The other problem with your logic is that it applies out-of-the-box thinking to areas where customization is of the utmost importance, and the out-of-the-box solutions are more difficult to customize due to the the fact that the developers of the cart aren't the developers of the sites using the cart. In your case, you want to have your cake and eat it too. Sorry dude...that just ain't gonna happen.