With regard to CDI scopes and servlets, I think it would be a really REALLY bad idea to try and support scopes for servlets and filters.
A request scoped servlet would essentially be much the same as a javax.servlet.SingleThreadModel servlet - which was a bad idea then and is still a bad idea now. It added needless complexity to the container whose cost was/is paid by all users regardless when most do not use SingleThreadModel.
I fear that trying to get similar support for CDI built into the core container will have similar no-taxation-without-representation issues.
I understand that scoped CDI may well be a good way to assemble an application, but I just don't think it is a good way to always assemble a protocol handler. Why is this level of integration needed to be supported in the servlet container itself. If a web framework based on CDI wants request scoped servlets, then it is free to write a CdiServlet mapped to "/" that will use CDI to manage it's own Servlet instances that it can delegate requests to.
The servlet container has a need to create and decorate instances of Servlets, Filters and Listeners in order to perform it's core functionality. I'm totally OK with making it possible for the container to out-source the creation and decoration of those components to frameworks like CDI, but only to meet the needs of the Container for the specified lifecycle of those components. This is entirely different to turning the servlet container into a CDI based web framework that can dynamically create servlet instances for requests - such features may well be compelling, but they can be implemented as a Framework and not as part of the container.
Integrating web frameworks into servlets has been and will be a mistake. Instead we should integrate capabilities required by frameworks in general. A Servlet and Filters are already plugable behaviours that can be used by a CDI based framework to achieve scoped request handling without the need for the container itself to be away of request scopes.
regards