Most of this issues only affect generalized solutions (libraries, servers, frameworks) and are solvable for concrete applications.
- it is impossible to have extensions to the protocol (there are extensions supported for instance by Thin, which Rack is explicitly removing again)
- no stack reflection (i.e. you don't know who's calling, is logging already set up or do I need to take care of it? who's taking care of encodings?)
- no state reflection (is the server actually running right now?)
- heavily CGI based approach (you can't do anything without actually processing a request at the time)
- stack configuration does not correspond to HTTP spec workflow (i.e. handling of chunked encoding, optimistic locking, caching, etc is suboptimal)
- concurrency is not decoupled from server, yet there is no proper way to communicate the concurrency model
- the app has no way of taking care of connection/stream handling
- a recursive stack yields bad performance with conservative GC (this is a MRI specific issue)
There are a few ideas for replacements, namely raggi's ideas for Rack 2.0, tenderlove's Ponies project and Webmachine. While Rack 2.0 and Ponies are more or less non-existing, Webmachine for one fails to make performance optimizations the design offers (though this might change in the future) and by the strict yet incomplete HTTP spec adherence is basically unusable for any projects involving heavy web browser interaction.
Getting something stable that works with both Rails 4.0 and Sinatra 2.0 and does not break too much existing applications is some large amount of work.