I do not know the exact policy for managing the domain of Nav Objects.
It is clear that all things having equal GUIDs should better be considered the same thing - this is the purpose of allocating unique identifiers.
Usually, the GUID is the _primary_ key, in OpenCPN
it seems to be a _secondary_ key.
Decision whether to allocate for something a new GUID or to associate it with an existing one, based on equality of attributes, is a matter of policy.
Whatever the policy is, I am not sure that we can or should extend its reach outside of OpenCPN processing environment
GUIDs identify concrete objects within specific namespace.
In another namespace, or under another policy, an identical object might be another thing, or an object with slightly (in the given metrics) differing attributes could be considered the same.
In other words, it sounds OK that GUIDs are used inside dynamic data structures, and that they are used in files and communication channels where the given GUID allocation policy holds,
I am not sure that - as a rule
- GUIDs should be used everywhere.
Half of this is presently implemented, since there are two versions of importing everything - with GUIDs (treated as secondary) or without GUIDs.
However, all objects are exported with GUIDs.
I think there should be two versions of export as well: with GUID or without GUID, depending on whether we mean to interpret the exported data as concrete objects, or just patterns of attribute values.
A Save/Restore (with GUIDs) would operate within OpenCPN policy scope
(this is definitely navobj.xml and these would be the backup files).
An Export/Import (without GUIDs) would be for environments, where the assumed object unification policy does not hold.
Of course, technically it can be done with simple text postprocessing, removing the GUID lines from GPX files, but it would be far better to implement the model explicitly ...
When building a route passing by a location of a Safe-Water Buoy Mark, the user is asked "Use the nearby waypoint?" The policy is to honor the answer, regardless of any attribute values the waypoints might have.
Without this user input it is impossible to decide, whether to share or clone the point.
A policy might say, that if the nearby waypoint has a name other than an automatic number, we share it, otherwise we clone it.
Depending on all this, zero or one new GUIDs are issued.
Imagine the user said YES, SHARE IT.
The route and the waypoint is saved with an identical waypoint GUID in them.
All is fine as long as we operate within this policy's enforcement capabilities.
The moment we send both routes into the wild, things break.
The route is sent to Ann, who edits the tricky point, moving it to North.
The route is also sent to Barbara, who moves the point to South.
After completing their respective circumnavigations, both routes return to us, and we import
Which of the points, if any, is good and which is bad?
In principle, the user should be asked again to choose... that should happen with Save/Restore.
In 2.4.x, we reasonably assume that the guy who was here first takes the floor, but even then we get two or perhaps three clearly different points with the same GUID. How to interpret this? Will they be merged again if all the attributes meet equal some time in the future? I guess not.
The point is, that once we know that we can no longer enforce the policy, we should not issue GUIDs nor respect them automatically, if present.
This should be called Export/Import.
Seems a safe step to take, regardless of Policy.
Another step would be to verify integrity of GPX files and remove GUIDs where results are doubtful.
Or am I getting it wrong?