The left-hand side of .eq() can be more complex than just a signal name. For example, you can do:

m.d.sync += buf.word_select(idx, 4).eq(input)

This is not representable with the syntax you're suggesting.

(Aside from that, this proposal violates Python name scoping in a way far more substantial than what nMigen already does, but that's a secondary issue compared to the one above.)

@whitequark how about this approach: m-labs/nmigen#345? I created the issue in the wrong repository by mistake.

Personally, we find that this sort of change obscures important details about what's actually occurring when you assign a signal in a domain like this. You're adding a new assignment statement and the code itself should reflect that. Beyond the potential implementation issues, this fact becomes important because later assignments can override earlier assignments that have been added.

The proposal as submitted has a fatal issue: it makes a substantial amount of existing code unrepresentable.

The proposal as modified later has a fatal issue: the code style it proposes makes it impossible to reuse the decision trees built through If/Switch statements to drive both combinatorial and synchronous signals in the same statement body (or at least the same decision tree). This was one of the substantial issues with Migen that Amaranth aimed to address.