Just a wild guess, since I can't know what data, in what format and through what process does the game store and save about the PRTs (and I don't know / can't remember if the markers were ever saved and restrored properly and just got broken somewhere along the line, or they never saved properly to begin with).

Could it be possible that somewhere along the saving process some overlapping data related to the "first" (in the order of discovery) PRT gets lost / overwritten by the data of the second, because somewhere during procesing it you expect(ed) only one PRT to exist and use only one object/variable/dataset/whatever to store the discovery flag and/or the fact that that specific PRT needs to be readded to the map? Or maybe when restoring the map markers from a save, only one PRT position gets added for the same reason, bacuse somewhere you went "there will be only one so I'm not iterating though a dataset, just read and mark one PRT"? As in, you store / process it as "the PRT was discovered" instead of "this PRT was discovered".

If only one marker persists through a save from the beginning (which I don't know if true or not), then something like this could be a prime suspect, some unintended data loss either at writing the gamestate (the data related to one of the PRTs is only partially saved) or restroring it (the data related to one of the PRTs is only partially restored). If they persist through several saves and then one disappears for no apparent reason at some point, then its more like related to something with the discovery system itself (still could be some partially overlapping data, where an event triggered by one of the PRTs affects / corrupts the data stored about the other).

This is a save with 2 PRTs, but only one of them being marked on the map. Both are by the hab the save was made in. The one across the airlock door is marked, then one to the left of it (as you exit) isn't. 2_prts_map_marker_issue_save.zip

This game was originally started in 0.64p1, then loaded into 0.64.1 for testing some PRT related things. I cannot remember if the map markers behaved differently originally in the previous version and only got broken during the transition, but only one being marked appears to be a consistent behaviour now.

I just finished a lengthy test session in 0.64.1 with the save from 0.64p1 I mentioned above and I could not recreate the issue in about ten test passes under various circumstances. The PRTs in 0.64.1 appear to be settling on the ground properly every time (save for one odd incident not related to the original report: at one time after I got out of one I heard several "thud" noises behind me and when I turned aroubnd I found the PRT to be doing a hand stand, so to speak, It was hanging in the air almost vertically and tilted to the right, with only the right front wheel touching the ground), regardless if there's one or two at the given location. I think loading into a cell with one or more PRTs still causes a lot of extra loading and freezes, but nothing on the magnitude I reported above.

So whatever was causing it previously either was some transient thing (I did several tests back then and the behaviour was consistent within one game session), or some change between 0.64p1 and 0.64.1 made it go away.

It's not certain if only one PRT would float as I never tested it with leaving both at the same locaion, moving out of the cell on foot then moving back. I know I saved once in a hab with both PRTs parked outside, but in that situation it doesn't happen with a single PRT either; I had to move to a different cell then back to get a floating PRT.

I found a save snapshot that might have been made when I encountered this; I'll have to load it up and see if it indeed is the one with two PRTs and then I can do some tests. However, it was made in 0.64p1, so the version difference might introduce some "false positives" to the testing.

I'm getting performance issues in general, due to the artificial memory limit the game apperars to impose on itself (never using more than exactly 1.2 GBs, no matter what) as I've mentioned elsewhere, but these severe stalls I've only seen in that game and only when I entered a cell with an already discovered PRT in it.

I loaded the save in the opening post into 0.64.1 and the indicated slot no longer showed the issue. However, see the new example saves I just posetd made in 0.64.1.

I made a few new saves afterall.

Electrical wire 3 and 5 are bugged: component_slot_issue_1_save.zip
Electrical wire 5 and Reoxy hose 1 are bugged: component_slot_issue_2_save.zip

Additionally, I also got bugged tank slots as I mentioned above, before I realized that turning the system on makes the issue go away so I couldn't save with those. So at least these slots appear to be affected. I never saw broken fuse slots being affected.

In the 0.64.1 save I've encountered this I've fixed the slots already, however, I think I may have found the reason why you no longer saw this.

Apparently the slots are bugged only until the system is powered on for the very first time, at which point any affected slot gets somehow fixed and behave as expected. This also means that it may be difficult to provide a save, since you need an online hab to be able to save, but at that point the systems will have been turned on, fixing the issue (ok, if you get a first hab with oxygen supply, you only need to fix the heater to be able to get the helmet off and be able to save).

What you need to do is keep starting new games and checking the systems condition of Hab Alpha before turning them on. Two out of two tries I got at least one bugged slot (oddly enough, in both cases it was a tank slot on the reoxygenator) so I doubt you'd need to spend an excessive amount of time with starting new games to get a test case.

It's also possible that it only affects certain kinds of slots for some reason. For example, two out of two tries I got broken fuse slots with fuse in them, and they did not have this issue. I think I've seen it on tanks and hoses almost certainly, and maybe on a circuit board once.

I knew there was something about this already. I can't remember if I have tested this back then, but currently in 0.64.1 it is not possible to use neither canisters nor batteries while inside a hab and with the helmet being on.

And now it's back in 0.64.1. Initially broken slots again give good components instead of broken ones.

Sadly it doesn't appear to be fixed in 0.64.1, I'm getting the exact same behaviour as before; initilally broken slots are mirroring the last good slot I've interacted with (if any).