I always had tons of fuses, in my "long" game in 0.57 (66 sols) in the end I had like 60 or more of them (not counting the excess ones  had installed into systems just to have them removed from inventory/storage), so many that I had to start dumping them (and a lot of other items) back into white locations to free up Hab storage space.

I'm still not sure why/how people lose system components. I never had to craft/replace anything, ever, in none of my games so far so there was no need for constant influx of materials/components. The WayStats may change this a little, as you'll need at least 16 fuses if you want to bring them all online, and at this pont I don't know yet how feasible it is to keep them running (as in, what's their slot deterioration rate) given their number and the distance you may need to go regularily to check on them.

But as a wohle, I don't think fuses are a problem, they seem to be abundantly available. What I constalntly saw a shortage of is Heating Elements. Now those are indeed scarce. There was a game where I still had only 4 (including the ones that were installed in Habs) even after having explored about 70% of the map. (Then again, there was one where I had 8 or so, but that was an exception, I usually see far fewer than that.)

I had a similar idea, only more along the lines of item transportation. The Drill Rover, since it has some storage space, after some in-site repair/repurposing could become an autonomous transport vehicle which can be set to travel to any discovered location on its own and wait there until further (local) command. Then the player would also go there eventually, fill the storage space of the rover with, for example, items from a resource site, then command the rover to move to any other location (eg. to a habitat for later unloading) where it would again wait.

Rovers could break or run out of power en-route (or even encounter terrain which it can't negotiate and would have to be given new commands locally or helped along by some local control method), which would then require the player to go to them and fix the issue so that they can continue.

And the cause is even weirder than expected... At any rate, I'm glad you managed to catch it in action and figure it out. Reporting things only I seem to be getting makes me uneasy and wonder if it's something on my end only.

The problem with reporting "offline" while there is no power input but the unit is otherwise functional and thus not needing actual attention is that it's the same reported status as when it is not turned on or is in fact broken and not operational, and thus does need attention.

It was very confusing when I saw that Electrical was "offline" since I was pretty sure I did turn it on and repaired any low component states. Going out again and rechecking, I still didn't find any reason why it would be not operational as reported.

Uniform and more descriptive states would work better, with seperated "state words" representing the three condition category: functionality, power supply, production state.

Functionality: "Offline" (red) when not turned on or inoperative due to broken components that need repairs. "Online" (green) when turned on and does not need immediate repairs. Does not depend on input resource of power availability, strictly on if the unit is functional or not. When offline for any reason, the other two state strings are irrelevant and thus not displayed. In "Online" state the "Online" state word may be omitted as the presence of the other two implies that the unit is functional but may be in a non-producing state, but still may be preferrable to explicitly display online state nonetheless.

Power supply: "Local Power" (green) when local power generation (panels or RTG) is currently supplying full 100% (or more) power. "Reserve Power" (yellow) when local power doesn't fully cover the power requirement and the missing amount is drawn from the reserve battery. "Power Loss" when no local power nor reserves are available, thus the unit does not drain nor generate resources (but technically still online and capable of functioning). If power supply is "Power Loss", then the third status word may be omitted since it is implied that without power the unit cannot produce, but still may be preferrable to explicitly display production state nonetheless.

Production state: "Producing" (green) when input requirements (power or water) are met and output (oxygen, water, reserve battery charge) is being generated. "Not producing" (red) when input requirements are not met, with specifying what is missing, eg. "Not Charging - No Power Input" or "Not producing - No Water Input". For the electrical system, "Not Charging" should be reported only when power input is 0%, for anything higher it should charge, only at lower rate (already implemented).

For example, a functional Electrical system at night would report:

"(Online, )Power Loss(, Not Charging - No Power Input)" (green, red, red)

A functional Water Reclaimer at night:

"(Online, )Reserve Power, Producing" (green, yellow, green)

A functional Reoxygenator with no water available at day:

"(Online, )Local Power, Not Producing - No Water Input" (green, green, red)

I was lucky (at least in terms of getting the issue to show quickly; in terms of gameplay, this is a failed start: I have no oxygen reserves to speak of, nor food, and the storm will deny exploration and resource generation for the next 2-3 sols, which means I'll either starve to death or suffocate) with a new game as the storm practically spawned on top of Hab Alpha.

Load dust_storm_flicker_save.zip and step out of the habitat. For me, the red night time "dust fog" turns on/off at random intervals (standing still or moving, keep turning to different directions or not doesn't matter). Same for the day time version if I wait for it. To try to minimize system load in case it indeed is related, I turned graphics settings all the way down; same result, same random flickering at minimum, medium and maximum settings.

I doubt it's lack of system resources or anything like that, considering how the rate of flickering seemed to be tied to how far I was from where the bulk of the storm appeared to be. There was, for example, an area where I could effectively turn the effect off and on by moving back and forth along a 100-150m stretch of terrain (sloped, inclined towards the "off" end, maybe that also contributed ot it); on the closer end the effect being permanently disabled, while on the far end it turning on at least for short periods.

And you kind of answered your own question: what can turn the effect on and off instantly is if the game, for some reason, "thinks" that the player is somehow "jumping" from one position to another then back compared to the storm, or that the storm is somehow "jumping" back and forth between positions. Rounding errors, variables reinitialized/overwritten, type conversion (eg. losing precision), change between pointer/value based argument passing, player position detection issues (in other Unity based games I've seen various issues stemming from the engine momentarily losing track of the player controlled entity in terms of the game world/terrain, sometimes needing various workarounds to remedy), there can be several reasons which the position sensitivity I observed hints at.

In the save I have now the storm has passed so nothing left to see. I'll try to start a new one and see if I can set it up and save in such a state that there are distinct areas where the effect is (mostly) on and where it's off or at least noticeably flickering.

Increasing the capacity of the reserve battery, without increasing the charge rate of the electrical system, or even slightly reducing it so that during a normal day it recharges just a little more than what the systems need for a single night, would also give means to counter the effects of a storm. Actively managing power use in the days prior to a storm by turning systems off to allow Electrical to build up more reserves than needed for a just single night, the player could prepare for an outage. Then once the storm has arrived, they'd have to ration the reserves by again turning system on only for as long as absolutely necessary.

This would, however, eliminate the "trickle charging" of the suit while inside once the Hab reserve is filled, as it could never get filled.

If solar panel output would never drop to 0%, only to a reasonably low level, even in the densest storm, then it should be possible to survive even when you are in the only Hab available to you and without an RTG (pretty much the Big Storm scenario, unless you chance upon an excavation tool AND a buried RTG).

I did surive it, but only by way of shutting down every system, and standing outside in front of the Hab with the portable panel equipped all day long for two sols, feeding the Hab battery with the "exploited" charge of the suit so that I can generate oxygen from the reserve water I had (turning on the Reoxygenator for a few hours only) and run the Heater for short periods. Without the portable panel working, it would not have been possible. It was actually fun to figure it out, except for the part where I had to use this bug of the portable panel to pull it off.

However, if there was a way to get at least some power even in the densests storm, then it would be possible to survive. The only change needed is that the power generation never drops to 0%, only get reduced to, 10-15%, maybe. Then what you could do, for example, is filling all 5 mounts of the electrical system with the highest capacity panels available to you (eg. moving over the best ones from the other systems) to gather as much charge as possible during the day, while the rest of the systems would be turned on only for short periods as needed.

By "overfilling" the electrical system with panels to the level which normally would mean up to 250% power generation (of which the excess 150% would be lost) with the output severely reduced but not completely shut down by the storm, you'd still get some power collected (eg, if you had 5 large panels installed on the electrical system, and the storm would reduce panel efficiency to 10%, you'd still get 25% charge). This would also require the electrical system not to consider itself offline unless it has at least 100% power input, but be online wherever there's non-zero power from the panels.

I don't think adding items only to ensure survival (eg. making sure an RTG is available) in an unfortunate situation is desirable as it would go against the "be creative and come up with a solution" gameplay element the game should aim for. Instead of adding such artificial survival aids, opportunities should be created which, when spotted and used right, combined with some adaptation to temporarily changed conditions, would make it possible to barely surive, but survive. The current complete denial of power generation for several sols is not something the player can work around by any gameplay means (which do not rely on random luck, that is), so it's not an optimal approach.

Did you check what's in the Hab storage? I think I had a similar situation with the only heating element in the Heater broken, but there was a spare in Hab storage. My case may have been due to a "failsafe" that spawns whatever is critically needed to ensure Hab Alpha can be powered up, or it may have been only luck and you can get such a failed start condition currently.

While the name "Multitool" kind of hints at this, still, explicitly adding all of the tool types all the different tools can satisfy to their description (as the Multitool currently only lists Cutting and Building, but not Engineering) where applicable would help determining with certainty which can be used in which cases.