When using respawn template MenuPosition if a marker is added via BIS_fnc_addRespawnPosition that does not have a TYPE it will not display in the menu and has the knock on effect that other position names do not correspond to their correct positions.

For example take the linked test mission. When you spawn use the action on the player called "create respawn positions", respawn and compare the positions available to the linked test image for how they should appear. Also note how the positions have the wrong name applied where a marker of TYPE "" has been skipped.

Now load the mission again and instead use the action "create respawn positions with TYPE". Now when you respawn notice all positions are available and correctly named (markers are named as location positions see ALSO at the end of this report).

Now if it is intended that you can not create a quick marker in script and add it as a respawn position without setting its type then addRespawnPosition should check for this and show you an error.
I personally think it should be allowed and instead the markerType check in fn_getRespawnPositions
if (markerType _x != "") then {_x};
should be changed to....
if (_x in allMapMarkers) then {_x};
to make sure it still exists.
I suppose you could check for...
!(getMarkerPos _x isEqualTo [0,0,0])
but this could break if a mission maker was using a marker at [0,0,0] for something.

The isNil check on _pos further on needs removing aswell to allow nil values to be pushed into positions so the names stay insync with their positions, this is the main culprit for the desync, and instead add a check in fn_respawnMenuPosition for a nil value when adding the positions to the list.

ALSO note how adding a respawn position as a marker with the name argument via BIS_fnc_addRespawnPosition does not use the supplied name when viewing the respawn menu.
Maybe replace in fn_respawnMenuPosition ....
_text = markertext _x;
for
_text = [_respawnPositionNames select _foreachindex,0,"",[""]] call bis_fnc_paramin;
if ( _text == "" ) then { markerText _x };
So it uses the supplied name or falls back to the markerText, if thats not present then later in the script it falls back to location data, as it currently does. {F26347} {F26348}