> Again I don't see why this is more complex than the flattened version.
The need to merge two hashes is not something that comes up for
newcomers at all.
Being able to store things in hashes? They can already do that.
This raises an interesting point, I think, in the difference in how Michael
views the project and how other people do. Is ansible primarily for
newcomers or for experienced users? The fact that newcomers don't need to
merge hashes is to me irrelevant as hypothetical newcomers don't remain
newcomers. The entire field of configuration management is, realistically,
for people with prior programming experience or at least the ability to gain
that experience relatively quickly.
Let's not over analyze the argument -- most advanced users don't need
to merge hashes either.
Michael, is it your intent that ansible primarily targets newcomers over
experienced people?
No, absolutely not. I believe most crazy complex CM setups in other
tools are the result of those that either have become enamored with
using *all* of a tool, and a tool that has allowed itself to grow
too large by accepting all user requests without paying attention to
the learning curves it is creating. Thus they grow without paying
attention to the asthethic of the language and ultimately feel
non-cohesive in the end.
So, in that regard, yes, it's a balancing act -- but there is nothing
you can't really manage in Ansible, but how you do it will be affected
by how Ansible wants you to do it.
As users fully ansible-ize their entire configurations though, their
ansible content should remain simple and accessible to everyone, not
trending towards becoming it's own
monster that requires tremendous hours of input to learn, debug, and maintain.
More importantly, it must be readable and nearly obvious to everyone,
so that when people less familiar with Ansible read playbook content,
they can undertand what it is going to do.
There will never be a spaceship operator or triple equals or anything like that.
In other words, there is no simple or advanced user -- as Ansible
doesn't want to be 'hard' at any level.
I only ask because I have a specific use case in which I define a bash hash
and then merge in additional (sometimes deep) layers into the hash as my
environments and other metadata get more and more specific. (I did this in
Puppet and each module can inject additional bits to the hash and then a
template renders it to json at the end for django to consume). This was a
real world use case where I wouldn't want to have to include the entire hash
when I want to change a single key 4 levels deep (which I have to do).
Sure.
I object to changing current behavior or introducing syntax that is
not immediately intuitive.
I also object to absolute arguments that lack of this feature is the
end of the world 
So far I've heard "change the way it works now so hashes don't
override", and "let's make underscores mean something different than
they mean now", both of which are non starters.
Propose a syntax where this doesn't look horrible or change existing
behavior and we can possibly consider things, assuming you're also
willing to write the patch and tests for it, and there is no
regression on existing behavior.
Though really looking in at the use case in different ways, and the
end result you want to achieve on the system, what you want to do can
probably be modelled in different ways to not need this either.