A higher level abstraction like you created for the CQRS journey to process commands would be really useful.

Something with a simple API that:

* uses queues to activate jobs (service bus, azure, inmemory) or time-based (schedule)
* that can run in process or in a separate worker
* leverage TPL to maximize throughput
* that can scale out to multiple nodes
* graceful exception handling
* load/stress tested

TearDown does not do anything with the LifetimeManagers supplied ootb. It should properly dispose object(graph)s created by the container

Exposing a unity-managed object with wcf through a svc file is a common scenario. It would be great if Unity could provide a wcf factory out of the box, so it would be possible to use it directly instead of writing our own (many examples on the web).

As a developer I want to be able to leverage a ClaimsPrincipal for the authorization checks using the Security Application Block. The claims that are recognized as identity or roles should tie into the authorization providers (AuthorizationRuleProvider and AzManAuthorizationProvider). Currently the AzMan provider seems dependent on Windows identities.

Allow ValidatorFactory to create a validator of more than one specified rule set or allow validator to validate based on more than one specified rule set...

One of the things I like most about Unity, is that Unity can build object trees, even if not all types used in the object tree are explicitly registered.
However, if I want to use a custom default LifetimeManager, I do have to register all types with the custom LifetimeManager, because Unity does not support a custom default LifetimeManager.
So, the request is simple: make the default LifetimeManager type configurable.

E.g.:
var container = new UnityContainer();
container.ChangeDefaultLifetimeManagerTo<ContainerControlledLifetimeManager>();

we have component_xx.exe with his dependency component_xx.data.dll and in log4net and log4j
you have the ability to include specify for namespace ex. component_xx_data.model to log only information’s and for component_xx_data.model.error to log only errors

Better Documentation on how to configure and use it.

Aspects such as a Logging, Authentication, Authorization, Performance Monitoring, Caching, etc... that do not require attributes but can be configured by interception. Though perhaps attributes can *also* be used to add them.

A common set of these would help remove a number of cross-cutting concerns from all manner of developer's applications.

I would like a simple way to use configuration to create performance counters to instrument systems.

Add support for Lazy<T> when resolving type T

Make Unity to be fully configurable with XML file.
Add support for
1) Factory methods and abstract factories;
2) Macros;
3) Building configuration from several files at the same time.

Make XML config file syntax more concise and Source-Control friendly.

Rapid integration with popular Microsoft Frameworks. For example:
Install-Package Unity.Mvc
- I don’t have to write a single line of code and my MVC will now use Unity
And so on…
Install-Package Unity.Http
Install-Package Unity.Wcf
Install-Package Unity.Win8

The Database Trace Listener and the supplied stored procedure are not really helpful over time. The database is growing indefinetly. It would be cool to have a similar mechanism as the rolling file listener.
The database can specify how large it can grow maximum and old entries are deleted automatically.

Not sure if this is app block or a helper (like the original and highly popular single file SqlHelper released by p&p circa 2006). Async is hard to grasp (easier with NET 4.5, but still). A higher level simple library that help us implementing common patterns and best practices on top of TPL (sequential/parallel execution, fire and forget, wrap sync libraries, coordination patterns, server side good practices, etc.).

See here for some of the needs:
http://bradwilson.typepad.com/blog/2012/04/tpl-and-servers-pt4.html

And then resolve all these instances by ResolveAll

Now to reference Unity I need to reference 3 asms: Unity/Unity.Configuration/System.Configuration. Change it to only 1, please. When I'm allways trying that my component user feel comfortable to reference only one "business logic" assembler, I should instruct them also to reference three additional dlls...

I would like to log the ActivityId field of the LogEntry class to the database when using a DatabaseTraceListener. ActivityId is not currently one of the values logged to the Log table.