Sorry to forget Zope 3... I think it was in my original writing but I edited it out that paragraph. Zope 3 is both better than Zope 2 for Python programmers, and maybe worse in terms of bringing in non-Python programmers. I don't really see it as accessible to an off-the-street programmer who isn't committed to Python already. But there's also a good possibility that something built on Zope 3 will provide that experience -- something that looks like Plone, perhaps. Or another application that is itself a framework, but a more directed framework than the open space of Zope 3 as a whole.
It's getting off the original topic, but I do have some problems with Zope 3 (I haven't used it a whole lot, so I might be looking at it wrong). But it seems to put modeling up front, with the web UI coming along for the ride. But I think modeling is really hard, but making a web UI is pretty easy. And I think it's best to do the easy stuff first. So I'd prefer a system where development of the application UI came first (in a crude procedural manner if necessary), and the model grew out of that. I don't think this describes Rails, or Subway, and certainly not Zope 3. I guess it describes PHP, except PHP is good for that first step and bad for all following steps. Rails I suspect is appealing to a more mature developer that has gone through the PHP (or PHP-like) process. Zope 3 is appealing to a developer with a level of maturity that, I think, is very uncommon.
That said, I'd certainly like to take ideas from Zope 3 as well in my future work. Once I figure out what they are ;) I've become wary of Adaptation, though I've only tried to use it once (but it wasn't very successful). I like interfaces, especially as documentation. I should learn more to figure out what else there is. Hopefully Zope 3 people will also start distributing more stand-alone packages, which I think will increase its visibility, and let people become incrementally more comfortable with its concepts before they jump in entirely.
You've misunderstood Rails if you think it doesn't support building the UI first and extracting a model from that. That's exactly the way DHH likes to approach development. You can write a Rails app that doesn't use a database (e.g. Instiki, a great Wiki based on a pre-release Rails, that uses a RAM/disk backend).
That means you can cruft up a UI, store values in memory or whatever, iterate until you like your UI, and extract a proper model.
If that's what you want, I suggest you give Rails a try, Ian :) (Apologies if you already have.)