Hey, A few points instead of a point by point reply. * I thought we had agreed to add methods to Interface that support multi adapter and utility lookup. We seem to have, but only about the external API, not about where the implementation is. (even if in my plugin proposal the implementation still lies in zope.component) * Apparently not even single adapter lookup is supported by you, at least as implemented in zope.interface. I had not previously realized that the current implementation of __call__ could be considered wrong by you. * You appear to be looking for something that at least in the Python language is only accepted as a kind of hack: an ability to extend the API of an existing class far away from the definition of that class, without there being a subclassing relationship (or I suppose, a class decorator). The idea in Python is generally that the API of a class is defined by that class or its base classes, not elsewhere. * There is of course a way to extend what one can do with an object in Python. Subclassing is one way, adaptation another, and defining functions another. The last is what zope.component does. * I do not know of a user community that uses zope.interface and does not use a component architecture. The Twisted community for instance uses zope.interface's adapter registry and __call__ hook. This is an argument for making component lookup an integral part of zope.interface's responsibilities. I think you could even make an argument for folding zope.component's responsibilities into zope.interface, though I'm not currently proposing this (also because we're are looking to improve the implementation, see below). Generalizing what kinds of component lookups one can do using Interface seems like a good idea from this perspective. * I think it is entirely possible that people will plug in alternative component lookup strategies to zope.interface in the future, as the long discussion also involved changing the way zope.component's internals worked. * All this questioning of fundamentals makes me inclined to give up on this project for the time being. I thought we had reached a conclusion, but I was wrong. Too many cooks? Some more technical points: * you wonder about a 'context' parameter. Are you talking about the lookup context here? We hadn't considered passing through the lookup context in previous discussions. We could leave that out for the time being. * A single plugin seems fine instead of a list of plugin points for zope.interface. I think a single plugin, using a global would be the most straightforward and readable solution, but perhaps some performance measurements would be interesting. Regards, Martijn