I think supporting lists in geometry nodes is a perfectly reasonable thing to do. Having nodes to get/set attributes of a geometry and nodes that deal with lists in general can be very useful. However, I also think that this should not be our only solution to the node-tree-linearity and temporary-attribute-names problems.
Passing all attributes around as separate lists does not seem to be a viable solution when you don’t know all the attributes while building the node tree. Building reusable node groups that keep existing attributes intact seems difficult. At least I’m not sure how it should be done in a good way. How would an extrude node work, that just works on lists as the one in Sverchok that should keep all attributes on the geometry intact?
The idea mentioned by @LudvikKoutny is actually the foundation of the “fields” proposal I mentioned before sometimes. We’ll try that as well to see if we run into any major issues.
Fortunately, lists and fields don’t really conflict with each other. They could benefit from each other quite well actually.
@Joze that is a separate problem that we are working on as well. See T87009 and T89140.