The reason Value.part exists in Migen (I think; @sbourdeauducq could confirm) is that it lowers directly to Verilog's indexed part-select construct: x.part(s, N) → x[s+:N]. Or at least was supposed to, because the semantics of these constructs don't match (m-labs/migen#168), and it's not valid on LHS anyway. In reality it lowers to something like N'(x >> s) on the RHS, and is legalized on the LHS.

We're stuck with this operator in nMigen due to backwards compatibility, but I think it is not very useful: it is essentially a bit-slip primitive, whereas most applications for indexed part-select call for a word-slip primitive, which would essentially be x.<oper>(s, N) → x[s*N:+N].

It would be good to have a word-slip primitive as first class, because it is a relatively common operation that is awkward to do in nMigen. The obvious solution x.part(s*N, N) is bad for several reasons: it requires duplicating a part of an expression, which is prone to copy-paste errors, and it expands to inefficient code (multiplication followed by a shift) that may or may not be optimized away, and in my limited testing is not handled very well by toolchains. The correct solution Array(s[x*8:x*8+8] for x in range(len(s)//8)) is very tedious to write each time you need it, but expands to efficient logic.

Bikeshed: what should it be named? Value.chunk? I'm worried that, part being nondescriptive as it is, you'd never remember which of the part or chunk (or a similar new operator) one should use. Perhaps it would be wise to rename the operator to something more sensible and deprecate part, retaining it as a compatibility name only.