Also--we do indeed use the embedded Jetty model for serving web apps. It's entirely up to a user of the framework to decide how many apps they'd like to run in each embedded Jetty instance.
One minor point of clarification: this framework is not intended to prescribe that we (Puppet Labs) or anyone else should move all of their services into a giant monolothic process, a la JavaEE. In fact, that's one of the main reasons we decided to build the framework rather than use an existing solution.
Trapperkeeper is simply intended to give us the flexibility to decide how to bundle different services together. If we have 2 or 3 tiny web services that can benefit from some shared state and are lightweight enough that they don't really warrant running a separate web server for each one, now we can choose to deploy them that way. But, absolutely, we can still run more than one instance of this framework on the same machine, to reap the benefits of truly isolated OS processes in cases where that is appropriate.
Another minor point to highlight is that, at Puppet Labs, we're building on-premise software that our customers install and administer on their own networks. We're not building SaaS products that we administer ourselves. This means that we need to be able to support a wider range of deployment configurations, so that we can tailor a particular installation to the needs of the particular user who is installing it. For some users, they may have enough traffic to warrant peeling out every individual service to its own process and distributing them across many nodes. For other users, they may have a very tiny network where it is perfectly sufficient (and much simpler) to run everything in a small number of processes on a single node. The new framework is all about giving us the ability to make those choices more dynamically--not about prescribing a particular deployment model to all users.
To be clear: these changes should be totally invisible to most or all of our end users. We'll still be packaging our server-side applications as rpms/debs/etc., and none of the client-side tools are changing at all as a result of this. So you won't need to learn any new syntax. If you're using PuppetDB, then you're already using this new technology stack; we're just making it more modular so that we can re-use it in other places.