Interesting.

Regarding the first point :

Do those "Edit mode nodes" accept a mesh as an input(without getting into the "baking evaluated mesh" problem)?
If so, how can one decide if their input is an evaluated mesh or the original mesh data?
Or do you mean more groundbreaking changes that would also deprecate the original edit mode entirely?

Regarding the second point :

The main scenarios I thought of are :

1. making a tension map
2. making a sculpt layer - in which you need the original data to transfer the position per UV map coordinates

Sure, one can make those with the current system, the problem/discomfort is when trying to make a distributed asset.

An asset should be a plug-and-play thing.
Without needing to duplicate-linked the mesh or put an additional geo node to keep the original data.

Another thing to note is that including mesh_deform_eval may also be useful. (for deformation modifier only)

What about a mesh input?
if users wants the raw data, they can simply access bpy.data.meshes

cleaner solution isn't it?

original_vertex.co - evaluated_vertex.co is useful to store displace maps as images for use in VAT

we should create a output context for geometry nodes to bake images and to use these as input later to accelerate stuff using geometry nodes / bake it.

eevee next has GPU displace now, and cycles always had true displace output so it should work in both engines.