I just had the thought, maybe "Index Offset" would be a better name for this. Two benefits:

• It doesn't break the "field is not really data, it's just a function" idea
• It makes it clear how the offset works-- it's offsetting the index in the array by a certain amount.

My design question here is whether we want offset or "get" behavior.

• Offset is based on the existing index, with a default of 0.
• "Get" is more like the transfer attribute node, with an implicit index input.

Both of these are possible with the (badly named) transfer attribute node, just in a very clumsy way. Maybe it's worth watching what people do with that. Or having both features available as modes or separate nodes or something.

In D12761#343470, @Hans Goudey (HooglyBoogly) wrote:

My design question here is whether we want offset or "get" behavior.

• Offset is based on the existing index, with a default of 0.
• "Get" is more like the transfer attribute node, with an implicit index input.

Both of these are possible with the (badly named) transfer attribute node, just in a very clumsy way. Maybe it's worth watching what people do with that. Or having both features available as modes or separate nodes or something.

In general, I think there is room for duplicate functionality (for basic tasks rather than uber-specific use cases) when the 'other' way is cumbersome, hackish, or too unruly to accomplish. If you can do the same task with just a couple nodes and conceptually the idea fits in the context of what you are trying to do (not using side effects of some other node) then maybe not duplicate. But if the other way to do it feels like a 'trick' then perhaps it is a good candidate for functional duplication in a nicer package. In the end, we want the tools to be intuitive.