The "extended" interaction hotspot doesn't appear to be linked to having 2 PRTs on location. I just got it twice in a row in 0.64.2p1 with only one PRT present. It affects only the "Inspect PRT" hotspot, but not the storage one.

It was in this state when exited a hab with the PRT next to it (which I did several times before and it did not cause the issue to happen until now), and it persisted between entering the hab and exiting again (which it did not on the previous occasion). However, it didn't persist through a save and I still don't know what could have caused it. However, it seems to be not that rare (it happened 3 times in 2 game sessions with PRTs present) so maybe you could try to play around a bit with PRTs (drive around a bit, exit, enter a hab, exit a hab, walk away a bit, walk back, walk to the next cell and back etc. and check the PRT in between these actions) to see if it triggers in a reasonable amount of time.

So, I was more or less right. The photo based waypoints break when set while inside a habitat, but only when this is the first ever waypoint you set in that game session. Once you have set something else, photo waypoints will behave correctly regardless of where you are when setting one. Reproduction:

1. Start the game and load a save (important part, do not just test on a game session already in progress, save, quit and continue if need to).
2. Exit the hab you are in and take a photo a little ways away from it (doesn't have to be far, 20-30 meters is fine, a short distance helps immediately seeing the incorrect placement).
3. Enter the hab and save.
4. Exit to the main menu (or quit completely, but main menu is enough).
5. Continue the save.
6. While inside the hab, set the photo you've just taken as waypoint.
7. Exit the hab (if you have made the photo close to the exit, you'll notice that it's now suddenly +100 meters away) and follow the waypoint. When you have arrived, it will still show a distance of approximately 100 meters.
8. This specific photo waypoint will remain incorrect even when setting another and then this one again, as long as you don't make another interior/exterior transition with this or another waypoint selected. After that, all waypoints will behave correctly in this game session.

I have a suspicion about what might be causing this. I think I set that specific waypoint where I observed this the last time while I was still inside a habitat (there was a radiation storm so I wanted to minimize the time spent outside, thus I checked the photo locations before exiting to see where is the one I was thinking of going to, then left that waypoint active as exited) , while I usually set photo waypoints when already outside. That would explain why I saw this rather infrequently, and even makes some sense since you are on a different map while inside, and I could see that interfering with a location information that is not tied to an actual world object, such as a habitat, when placing its marker on another map (the exterior one).

This is just a theory for now, I'll try to do some experimenting soon as time permits, just thought I mention it for the time  being.

Should be ok at a quick glance. So all habs should now start with frozen water so that there is no "conversion loss" as observed, and then when it gets heated it turns into liquid water.

This would also solve an inconsistency I meant to mention at some point: resource caches can contain water bottles, except they should be frozen solid by now as having been out there since who knows when. Now that there is a frozen water item, I think the possible water in the caches should be frozen water instead of liquid (drinkable) water, except you should be able to take those items out of anything that is not the hab storage, and be able to put them into hab storage so that they eventually melt and get added to the batch of liquid water.

On one hand this would mean you won't find "ready to drink" water supply while exploring so you can't count on that, but on the other hand it would solve the inconsistency.

It was mentioned in this topic, not marked as issue/suggestion since it contained several topics:

https://lacunapassage.userecho.com/communities/1/topics/479-another-year-and-some-really-great-improvements-have-been-made

Come to think about it, this issue likely affects all habs; the water they are initialized with will be lost due to the above, and they will effectively start from 0 once repaired and put online. It also explains why I've been noticing a severe water shortage (or rather, a lack of reserves, production being just slightly more than usage) in the last few versions, ever since the frozen water thing was introduced, compared to how it was before.

I actually meant to look this up some time so now I did, for reference.

The US combined IVA/EVA suit (EMU, AL7) from the Apollo era was 92 kgs in EVA configuration, with 6.5 hours independent life support, suitable for EVA on the surface of the Moon.

The current US EMU in use for EVAs on the ISS is 145 kgs in EVA configuration, with 8.5 hours independent life support.

The Russian Orlan EVA suits currently in use on the ISS are around 110-120 kgs (depending on version) in EVA configuration, with 7 hours independent life support.

Apparently another player has encountered the floating PRT issue again in 0.64.2, so there must be some yet to be identified cause that makes it happen intermittently.

https://lacunapassage.userecho.com/communities/1/topics/479-another-year-and-some-really-great-improvements-have-been-made

I kinda agree with #2, but maybe with a different point of view. I think another direction of rebalancing it would be to reduce the carry capacity of the player to 40/60 kgs, and increase the PRT to 50, or maybe even 60 kgs. You may think that 40 kgs is too little, and while from a gameplay perspective it might be, there are a few things to consider. The player character is a female, and even if a trained astronaut in top physical condition, being able to carry up to 50/75 kgs (which is likely around her own weight) potentially for a day or two across rough terrain doesn't feel all that realistic. And that's just the items you carry, on top of the weight of the EVA suit, which I'd guesstimate to be anywhere between another 30-50 kgs. So imagine someone carrying up to a total of 80-120 kgs weight for days... And while the lower gravity on Mars affects some aspect of carrying it as weight, it doesn't affect moving it as mass, imparting momentum to its inertia as it's trying to go on its own way uphill and downhill, gaining speed and slowing down, bouncing up and down with every step etc.

I recall #3 having been mentioned elsewhere, but I can't remember if there was a resolution / answer to that. The way I see it, even though going through the airlock takes no time in the game (now, it used to, and I think it still should), the procedure is not instantaneous and you'd still be using the suit supply while the atmosphere is replaced from martian to breathable. So if you empty your suit before all that starts, you will suffocate in it while waiting for the airlock to cycle (which, realistically, would take anywhere between 10-30 minutes at least; IIRC the EVA ingress/egress time on the ISS is around 40 minutes both ways, and that's just draining and filling up the airlock, not replacing an unbreathable atmosphere to a safely breathable one), so I consider that as intended.

A good thing that this popped back up, for the airlock door reclosing part. I'm almost certain now that it somehow has something to do with the boundary of the trigger volume(s) which should keep the door open while you are nearby, and that the player's presence sometimes gets "masked" by some geometry / model issue with the airlock model when they happen to stand right at the "wrong" spot. I had this happen on both sides of the external door, but I'm less sure about it for the internal door (I think it did happen there too). When I catch it happen and I don't move, it consistently happens as long as I stay in the exact same place: I click on the door, it opens then immediately closes again as if I'm not there at all. If I move just a tiny bit towards or away from the door, it will remain open when clicked on. On very rare occasions I even managed to move back to the "wrong" spot and have the door reclose again, but it's very hit and miss as the area where it happens appears to be extremely small.

I don't know how these things actually work in Unity, just trying to think along some general implementation of such things. Is the trigger volume defined/anchored to the airlock part of the geometry, which is not monolithic with the rest of the hab model but kind of a "prefab"? If so, maybe there is a very small "dead zone" where there is a gap between geometry, which belongs no neither so as far as the game is concerned the player is not actually there so no trigger volume is to be notified. Or, two pieces of geometry overlap in the wrong order so that the one that has no trigger volume creates an area where the player is detected to be in that one because it masks the other geometry "surrounding" it which has the trigger that would hold the door open.

I remember there was an issue where the player could fall out of the airlock room during transition and it was addressed with adjusting related models/colliders, so that hints at that there are several visible and invisible volumes defined in and around the airlock. That's why I suspect some of them may be misaligned in a way that causes the game to lose track of the player when they happen to be at the exact location of one such overlap, and as a result the door gets immediately closed since the game doesn't detect the player to be in the "keep open" zone.