in order for proximity shader to work you need to subdivide the object that will show the shading, but here’s a question is there some sort of workaround to make the proximity shader not being topology dependent (as in you can get clean proximity shading on the plane with one face).
i use either 3.0 or 3.2
this is the set up i use
Attributes can be stored on specific domains like points edges, faces, face corners, splines and instances, so you are pretty much limited to this.
We might see storing attributes on UVs but that is not implemented (yet I hope). This will give the ability to store attributes on UV maps on lower poly meshes.
You can try to store the attribute on pointcloud. That might be lighter to compute as pointcloud don’t have edges or faces. I never tried this method thou.
This intrigues me. UVs are just another attribute stored on face corners, how does “storing attributes on UVs” work? and how would it be any better than storing an attribute on vertices, since there are as many vertices as there are UVs? unless I’m missing something.
In any case regarding OP’s question you are right!
You can already procedurally do unwrap in Geometry Nodes. And you can access UV maps inside them.
Now take your geometry proximity and instead storing it on face corner or point you can store proximity value on a pixel that is mapped on a face with UV.
Not really - you would still need to store the info relative to some domain.
i.e. you would need to do something like this (not using proximity, but location allowing distance calculation - to get something more fine-grained, using proximity, you would still need subdivisions to have more points )
So, there just storing the location of an Empty.
So, you were correct to say that you need to generate more points, either by point-cloud, like above, or by subdividing the mesh.
Cheers!
You’ll notice from the example that even though the info is stored as a 2D vector, it is still limited to the Point domain - so my reasoning still stands (i.e. it’s reliant on the “resolution” of the torus) 
If you can store hair location with UVs then you can store other data as well.
Current:
Attribute data → Point (or other domain of choice)
With the UVs:
Attribute data → pixel → domain of choice (whatever domain UVs are using)
So essentially UV attribute acts like a subdomain for transferring the data.
Ah, ok - still an open question how that will interoperate with the Proximity node. 
I think this node just stores barycentric coordinates from the underlying face on the point domain as well, but I could be mistaken. I don’t think you can actually store information on texels (though that would be pretty cool).
Damn, am I wrong?
My dream is shattered.
I don’t know! I remember making a double-take at Brecht’s comment here : https://developer.blender.org/T98940 where he mentions textures as fields so… why not!
