Re: [PATCH] alias: restore support for simple dotted aliases

I see the appeal of the overlapping-namespace approach for maximum compat.

My hesitation is that it introduces a config model where a single key (`alias.foo.bar`) no longer has a clear interpretation, but instead is implicitly treated as both a historical alias and structured data. That feels harder to reason about and document.

For the regression, I would lean toward a narrower compatibility rule: restore dotted aliases except where they collide with explicitly recognized structured keys (currently `command`). That keeps behavior predictable while still fixing the breakage.

If we want to grow metadata in the future, it might be better to make that expansion explicit at that point rather than baking in ambiguity now.

I think the worst outcome from this thread would be moving the new alias syntax into a different namespace entirely (e.g., `nalias`). If namespace cleanliness is the priority, reserving `command` and `alias-*` still seems like the best path forward to me.

One question: do we consider the historical dotted aliases something we want to preserve indefinitely, or just something to transition away from? My assumption has been that they were an accidental side-effect of the config parsing rather than a designed feature, but I agree they are now part of existing workflows and need to be handled carefully.