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

[Jonatan Holmgren <jonatan@jontes.page>]

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.