I think selection should be a boolean attribute rather than a flag in an integer. This gives us options for storing it differently in the future if we want. It simplifies code because we can use generic utilities that work for all boolean attributes, instead of writing specific code for a flag.

Further, we might have to use a different way of identifying the selection layer than a generic attribute name. Currently, if someone makes an attribute called flags, thing will break.
I mentioned this problem a bit in T95965: Mesh Struct of Arrays Refactor (Edit-Data Attributes section), since we'll have the same problem for meshes in the future.
I would propose using something similar to AnonymousAttributeID, but called something like StaticAttributeID that could be used as a const global variable to identify edit mode selection layers.

I wonder what would be the advantages of using this selection draw buffer solution.
If I'm not mistaken, the current selection solution for hairs is to store the depth buffer and project each point of the strand checking occlusion with the depth buffer.
One advantage I see of the method with depth buffer is that it supports cases where more than one point is in the same pixel. And you can also deduplicate the code with X-ray selection.

I agree that it probably makes sense to move the attribute ID changes to a separate patch.

• I'm not sure what purpose a reference count would serve in this case.
• Ideally name collisions wouldn't be a problem, since CustomData can check whether the layer has a "static ID" and avoid using the name in that case.

I left some other comments inline in the meantime.

I was thinking more about what makes the attributes that you call static attributes different from other attributes. The main thing we want to achieve is that procedural processing does not depend on these attributes, right?
So maybe we can just make them builtin attributes (like position) with the additional constraint that the user can't access the data in a procedural context.
Propagation of such attributes should still work. Also outside of procedural contexts, the data should be accessible like normal named attributes (e.g. with the Python api).

More specifically, these "ui attributes" (not sure if that's a better name, maybe it is) are exactly like built-in attributes with these differences:

• Cannot be accessed with the Named Attribute, Remove Attribute and Store Named Attribute nodes.
• Cannot be used as input/output in the geometry nodes modifier.
• Is excluded when exporting geometry.
• Is excluded in attribute lists.

That makes them essentially invisible except from the Python API where they behave the same as other builtin attributes.

That only works if my initial assumption is true of course, maybe it's not.

This is related to T96848 and T97174.

[EDIT]
Thinking about it a bit more, maybe it's wrong to say ui attributes are built-in attributes in general. the problem with that is that there may be a dynamic number of ui attributes when e.g. a ui attribute is attached to every uv layer. Maybe such layers could just be tagged with some CD_FLAG_UI flag. They can be both, built-in and normal attributes.

Also see T97452 for a more complete proposal on how to move forward with the selection attribute.