Just to clarify, when I wrote in my post that I wanted to "port" the tasty backend, I fully intended to provoke a conversation about the laziest, err, most efficient, way to do that.
One of the promises of z3 as I understood it was the ability to import pure python modules and libraries and make productive use of them within Zope. I had read about basket, and was hopeful that might play a role.
One thing I don't understand about these WSGI entry points is which app controls the url mapping. Tasty uses the RestResource cherrypy filter to map urls to objects, and I have no idea how that would mesh with Zope's publisher. Then there is the SQLObject/ZODB issue - I don't yet understand how to efficiently model the User-Tag-Object model inside the zodb, and I also know many Plone developers, who work exclusively on that stack, are reluctant to deploy a relational database.
Beyond that, a full integration layer would do a little bit more within zope than plain tasty. It could integrate w/ Plone's search, expose vocabulary managers within Plone (with configurable policy, such as shared vocabs, private vocabs, folksonomic vocabs) etc, etc.
I do think that "little-apps" is a pattern that offers incredible promise for stitching the web together, and realizing the hype of the web 2.0, the web as a platform. We are hoping to demonstrate ways in which this strategy will keep us from becoming trapped in a silo (any silo), and become more capable of treating software as a service - where we continue to develop custom applications composed of lots of little ones. And the prospect of tag-enabling a legacy app without touching a line of bit-rotten code, or even a static html resource, is incredibly alluring.
I also think that porting backends to alternate backends isn't tragic, if the api, and the corresponding microformat become somewhat standard. Not terribly different than alternate implementations of an interface w/in a particular environment.