As for vert.x integration, do you mean wasabi can switch it’s backend from netty to vert.x? that sounds interesting.
Potentially. That's one avenue I'm looking at it. But the flip side being is I don't want to re-invent Yoke.
2. Don't use mutable JSON as internal data message format. It is too dynamic, takes a lot of space, and serialization is slow. Also, a static data class is always better than a variable JSON document-wise and helps the readability of the code. When I look at a function/method that accepts a JSON parameter, and not knowing what fields are in it (possibly five levels deep), it feels horrible. I think kotlin has this potential.
Right now in Wasabi JSON can be deserialized on incoming requests and serialized for outgoing. There is currently no static binding on incoming but that's on the roadmap.
2. need a RequestLocal data storage. Similar to Threadlocal, but is only accessible for each HTTPRequest. In this way you can get some 'Global' data but won't need to worry about syncronization problems.
Not built-in yet. But I've created Wasabi in a way so that pretty much every piece of functionality is an interceptor (i.e. middleware), and all the functionality you see in it right now is via interceptors. I'm guessing this would be possible too, much like some of the other points you mention.
We could discuss some of the other topics in more detail if you like. It definitely seems that you know what you need and have experience, so I’d be happy to have further discussions and even have you collaborate on many of these if you’re interested. Feel free to ping me offline or on the discussion group (albeit it’s quite dormant there).