I’m interested in understanding better exactly what the trade-offs are between fields and attributes. I’ve tried to read this whole thread, but I haven’t seen developers mentioning the repercussions of fields. I don’t think all of those repercussions were immediately apparent to everyone commenting on the fields proposal. I think coders can often see the long-term impacts of decisions more easily than users can, because every time there’s any conceivable ambiguity, they get smacked with it in the face and have to make a decision about how to handle it.
I’m still in the “who moved my cheese” phase of dealing with fields, unfortunately. It seems to me that one of the issues with fields is the ambiguity: when we get position, when exactly are we getting position? With attributes, that was clear: we say what position we’re operating on by our noodles. To deal with that ambiguity in 3.0, the answer is, “we get the position immediately before we start evaluating the GN modifier.” While I can’t put my finger on it, I have this intuition that we may have some trouble with turning attributes, mid-stream, into other attributes; that resolving the ambiguity in this way limits what we can potentially do with a single GN modifier. But this is only an intuition, something that feels risky. And even if it is risky, there are potential workarounds, even if they’d be clunky.
It seems to me that the main advantage to the fields implementation is that we no longer have the MixRGB/Attribute MixRGB kind of duality; unfortunately, the 3.0 implementation makes it look like that node savings is more than made up for elsewhere. And it seems to me that a fields implementation is not actually necessary to solve that problem, because it could be abstracted behind interface, with Blender silently making a decision about which to use on the basis of noodle connections.