I'm always puzzled when I read feedback about hab management taking too much time, not allowing enough time for exploration, because it really isn't the case. I think many players, for some reason, formulate an extremely inefficient strategy (or maybe it'd be more accurate to say that they don't have a strategy at all) for managing hab systems and then suffer from the restratints that doing so puts on them.

The most common mistake I see is that they want to keep everyting at 99% at all times, which is not needed at all. It's a lazy and very inefficient solution that indeed leads to not having time for anything else; a bad time management strategy for any survival game where one of the main challenges is how you split your limited resources, including time, between all the things which demand it. Maybe the game communicates something in a way that makes people think this is what they need to do (I don't think it does, by the way, the game never gave me any feedback on how I was doing things that would have prompted me to try to keep everything at 99% at all times; after having observed how things work and how fast the conditions change, I got a "feel" for what could be an optimal strategy to balance keeping everything in working order with being able to spend enough time with exploring for resources), or maybe people just want to settle for a very simplistic and minimal effort routine that doesn't require (re)evaluating the current situation and acting accordingly, just "maxing" everything all the time without thinking about it, which clearly doesn't work. (They fail finding a survival strategy that works, and are refusing to reevaluate and adapt when facing with this failure. In other words, they are not doing what a survival game expects them to do in order to achieve the main goal, survival.)

I only spend maybe 3-6 hours per 2 sols with repairing systems (since not more than that is ever needed), and then heading out for a 2 sols EVA while the currently used hab is running unsupervised and producing resources. During a 2 sols EVA, you can easily cover about 15% of the entire map on foot, and finding a PRT typically half way through speeds up the other half considerably. Exploring the entire map takes about 22-26 sols depending on how (un)lucky you get with dust and radiation storms. In all this time, I never lose a single system component, without trying to keep everything at 99% at all times.

All in all, I think game balance is just fine, some aspects are even too easy and could be tweaked a bit to be a little tighter. I have some assorted notes I might post about it some time.

The primary reason is simply to support gameplay by the activity their maintenance requires.

The in game explanation (which I think is in either their own documentation or the general systems documentation found in the datapad) is that they are separated from each other and the habitat by a safe distance so that a catastrophic failure of one unit does not damage the rest of them, multiplying the effort and material need it would require to restore viability of the habitat.

I think I figured out what's the deal with the third issue. It appears that the lighting state of the previously visited hab is applied to the one you are approaching now, instead of its own lighting state, and only gets updated when you enter (or rather, click on the inner door to start entering). Then it happens again with the next hab you visit, and the next, and so on.

What I observed was that I left a powered habitat with the windows and airlock being properly lit. I discovered a new hab, which was at this point unpowered, yet its windows and airlock interior were lit. When I entered, the lights went out and they stayed unlit as they should after I exited.Then I went back to the previous, powered hab, which now had its windows and airlock unlit I entered then exited.

It looks similar to the since then fixed issue where the current hab showed the status of the previous hab when the status screen was used in the exterior version of the airlock room, until you entered and exited, after which it was updated and showed the proper values.

The side windows on the North hab were lit on initial discovery even though the power was off at that point. I'm not sure about the porthole window on the inner airlock door (forgot to check).

Actually the other two racks also have a similar light soure in front of them, they are a bit less noticeable, but they can still be located with the datapad.

Apparently this area is also present on the outer side of the escape pod when the hatch is in the closed position.

And one thing that's more of a suggestion / question: would it be possible to "animate" lighted state of the airlock windows based on the door state, so that when the door opens, their light level changes accordingly? For example, when outside and opening the external door, the window should darken while the door is in the opened state as it doesn't receive light from the inside of the airlock room in this state since currently the inner side of it is facing the habitat wall instead of the airlock room.

A rare occasion of having to spend time fixing a bug coming with further benefits. :)

While it's difficult to judge from a single screenshot, but it looks like the overall light level is the same in the unpowered habitat as before, other than the local lighting near the window. Light coming through even a tiny window makes a lot of difference compared to a completely sealed and thus pitch black room (not seeing anything at all vs. being able to make out the outlines of objects, but not enough to see colors/details the very least), so I'd say raising the ambient light level to the point where it's just noticeable would make the scene look more natural.

Maybe repositioning the pickaxe model would reduce how noticeable it is?

When I come to think about it, the current position feels kind of weird, actually, holding the pickaxe at head height. Moving it towards the bottom of the field of view and closer to the center, just slightly offset to the right, could make its position feel more natural and maybe move away from the bulk of the HUD enough to get less of the light reflected?

It's a proper loading phase on cell borders, with the loading indicator present. Any other kind of "unscheduled" asset loading causes the came to stutter/temporarily lock up and also ignore any user input during that period, unlike during the background loading that occurs on the cell borders. This is more or less how it looks:

1. I hit a "cell transition border", the loading indicator appears and background loading of new assets starts as indicated by disk activity and the accompanying stuttering, while the game remains interactable and visibly running. The PRT still moves forward, can be turned, responds to terrain (shakes, bumps, wheel suspension can be seen following terrain, etc.) and user input.
2. The loading indicator is on screen, asset loading continues, the game can be interacted with. I press and hold the brake key and the PRT (although somewhat sluggishly) stops as expected.
3. The loading indicator is still on screen, asset loading is still underway, the PRT is now completely stopped. At this point I could reaccelerate, get out, open the datapad, etc., the game can be interacted with as normal while the background loading continues.
4. Asset loading gets finished, disk activity more or less stops, loading indicator disappears and the PRT is suddenly moving on its own again, without any acceleration phase, roughly at the same speed it did when the loading indicator appeared and background loading has started.

I suppose it's a lot less noticeable / harder to reproduce on a system with a lot ot memory and the game installed on an SSD, since those factors likely drastically reduce the lengh of the loading period, but on a minimum requirement system (which still runs the game acceptably in terms of CPU/GPU performance, the only big issue being memory and asset management) it can last up to 20-30 seconds which gives plenty of time to interact with the game during the loading period.