Dart's biggest competitive advantage is that it has teams building compilers, VMs, libraries, apps and tools. It is not just about syntax sugar. It is also about better debugging and collaborating, improved development cycles and so on.
It seems that what you ended up doing is, in fact, reimplementing things that were implemented zillions of times before. Am I wrong or the Pump middleware doesn't work for any WSGI app? If it had followed the WSGI middleware basic concept, you'd be closer to achieve the goal of reusable components across frameworks.
"Pump aims to replace WSGI entirely." <- this is very ambitious. :)
I have the impression that experienced Python programmers don't feel comfortable with web2py's controversial (some would call "unpythonic") approaches, like automatic imports or the use or exec.
I think you're confusing the general idea of cursors with datastore cursors, which require a query and can't be created "per request", but "per query". See:
It should be added to the documentation which datastore features it doesn't support, to warn users and avoid that the GAE support is misinterpreted as bad advertisement.
Does the web2py database abstraction layer support datastore transactions and query cursors? Or what datastore features it doesn't support?
(apparently the documentation doesn't mention any datastore feature it doesn't support but the last time I checked it did not support at least transactions)
A big advantage of webapp2 is that you can use existing (and probably future) SDK libraries without adaptation. Many App Engine services (blobstore, mail handler, deferred etc) use handlers made for webapp. With webapp2 you get all those handlers working out of the box with extra benefits: webapp2 is a lot easier to extend and includes the most glaring webapp missing features.
Also, you can use all the examples from the App Engine documentation with it, since it is made to be compatible with webapp. And later you learn the new, extended features.