Stating the state of statelessness:

After further checking the Indigo book, the point I was confused about is clarified but the core problem remains: if the service type has a state, there will be a need for static methods to keep some kind of meaning (the lottery ticket example).

But if the object is stateless, the problem is not creating many instances of the same service type, but increase the throughput of the invocation of the exposed methods.

This may require several instances of the service type or just one. It will all depend on the behavior of the CLR and Reflection's api.

More on this and Austin later...