Basically, what's happening is this: internal to Unity is a data structure called the PolicyList. This stores everything we look up by type: lifetime managers, type configuration, and so forth. PolicyLists have a hierarchical organization. If you ask for
a policy and it's not there, it'll ask it's parent policy list, and so on until the request is answered or the policy's not found at all.
One such policy is the build plan. This is, in a nutshell, the dynamically created method we build to create objects.
Here's what's happening. When you resolve from the parent first, it creates the build plan. This bakes in the parameters that were configured into the build plan. Then when you resolve through the child, it doesn't have a build plan,
but the parent does, so it uses that one.
When you resolve through the child first, it creates the build plan according to it's own configuration. The plan is then stored in the policy list local to the child container. This doesn't affect the parent container, so everything works as expected.
The obvious fix would be never to look up to the parent for build plans, but this could break other stuff that also creates build plans. The factory stuff is the biggest one here; if you configure a factory in the parent, you want it to flow down to the
child unless overridden. Either way is non-obvious behavior,.
I'm not going to promise a fix for Unity 2.0, although I'll be thinking about it very hard. There's some serious subtleties, and this behavior has been in there since Unity 1.0. Since this is the first report I've heard of this issue, doesn't sound like
it's hurting too many users. There's a reasonable workaround - don't do that. :-) Basically, don't resolve anything in the parent.
Parent / child containers have a number of issues like this which need some revisiting.