[Paul violates his own 'please move stuff to zope-dev' post, so I'm going to do so, too :) ]
Paul Everitt wrote Zope's usability needs to improve a LOT. I got a good dose of this when I taught a three day Zope course several months back. When you have to explain it to people, you really find out how baroque Zope can be.
The major problem I, and the people where I work, have is not just that DTML's syntax is, ahem, 'distinctive', but that when you have a problem, you really don't get enough to help you solve it. Often trying to fix a problem involves just randomly trying permutations of the DTML that you want, until you hit the magic combination. I've almost given up entirely on ZClass programming (for anything but the simplest tasks) in favour of Python Products for this reason - when my python is defective, I can find out very quickly and very easily _why_. Inside a ZClass, there's no real way to figure out what the heck is going on. This isn't just a matter of not being familiar with DTML - I've been smacking my head against it since Principia days. That I haven't just given up entirely is testament to the other parts of Zope (the good stuff) - no matter how clunky DTML gets when you start trying to do the logic of your site in it, the rest of Zope is good enough to make up for it.
Though I agree with Andrew that the problem isn't just DTML, that seems to be a locus. DTML *is* being used in a way that violates its design (separation of presentation and logic). But at the same time we at DC lead the way on this violation, and aren't actively promoting viable alternatives.
Python Methods are a promising approach, and one I'd like to see more work on - they allow the convenience of coding Python, without having to restart each time. I'm not _entirely_ sure about the security of them, but then, I'm prepared to take the tradeoff - the people who are working on the sites I work on all have logins to the box anyway (and if I need to give access to people I don't trust, then they don't get to work with the PMs).
I'll say this about an ngDTML effort: good luck. The current quandry exists for a reason: there are a lot of tough design choices. That which is clear to the Python hacker is obtuse to the HTML newbie. That which is clear to the DTML developer is inefficient to the parser/renderer. That which is...
I don't know that a different DTML will solve the problem - if anything, I'd guess it would make it worse, since the temptation to throw every other feature in would be strong. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.