Alright, let's start with your solution (it would be nice if you presented it in your question, node trees are always a good conversation starter):
I didn't put the UV (re-)unwrapping there, as it is just one of many workarounds around the shortcomings of this solution. This is the effect for Susanne: (keep in mind I've marked the seams red just for this GIF, the seam info is never accessed by geonodes; also I marked the seams manually and didn't unwrap with them afterwards, so there could be some inconsistency due to that…)
OK, time to do it the proper way…
If you have seams on your object and you want to read them, simply use this solution:
Geometry Nodes: set sharp or crease attribute for an edge
Except in p. 6. Select UV Seam.
If you no longer have the seams, then unfortunately some important data is lost. You can't fully recover the seam data just based on geometry + corner positions in UV space, because nothing forbids you to position two sides of the seam on exactly the same spot (as if there was no seam). The below solution should detect the seam in every other case: if an edge has a mismatch between the corners of its sides, it must have been a seam! The solution, then, comes down to implementing a topology node Corners of Edge, as somehow it is missing:
So let's first create a mapping that allows us to specify not just a face and a sorting weight, but (face, edge, vertex) tuple, which uniquely identifies each corner. Since each corner has exactly one associated vertex, and exactly associated face, the only problem to solve is that each corner has two associated edges - therefore I duplicate the geometry convert corners to points (because corners can't exist outside of faces and can't be found using Sample Nearest node), and set both branches' positions to $x=$ corner's face index, $z=$ vertex index, on one branch set $y=$ "previous" edge, and on the other $y=$ "next" edge then join those branches together. Now each corner has become a point, has retained it's
UVMap attribute, and is positioned based on the indices of its face, edge and vertex:
Eh, I'm such a graphoman, so much text for just 9 nodes… This positioning on indices (typically with just a single index triplicated upon a conversion to a vector) is a common pattern in geonodes and shouldn't require that much explanation…
All we need to do now is for each edge, is to construct this (Face, Edge, Vert) tuple, by taking its 1st vertex index (easy, Edge Vertices node), self index (even easier, Index node), and 1st face index. Read from the mapping the corner associated with this tuple, and then do the same with the same tuple but with 2nd face index - 1st and 2nd face indices are the indices of the neighboring faces of the edge. If the UVs match - repeat the same, but this time with the 2nd vertex of the edge. If the UVs match again - it's NOT a seam:
There's just one problem… WHERE'S THE Faces of Edge NODE??
Again, need a mapping… That part I've already done here:
geometry nodes - Get Faces of Edge
The whole setup then becomes (together with the "Naive approach" for comparison):
Blender 4.0 is currently in βeta, meaning it can be buggy but its feature set should remain unchanged, including the Corners of Edge node. This means people coming here in future shouldn't have problems using this setup in Blender 4.0.0: