There are a couple for which I noticed this:

• For the custom upper stage, bottom radius adjustment isn't sticking at least if the main diameter is adjusted: tested on ST variant with a main diameter of 3.75 + 0.6 adjustment, bottom rad adjustment 0 (defaults to 0.3 and then defaults back again at scene change)
• For engine clusters, the height adjustment doesn't seem to be sticking. Tested with the generic shroud mount on a single RS-25.

Yeah, the bottom fairing

Ahh, thanks; noted.

About time to do another cleanup pass on the fairing interaction anyhow... it has a few odd issues like this that I need to sort out.

Engine clusters -- noted and fixed.

Upper stage -- not sure what you are referring to? What bottom adjustment (that module only has a single diameter/radius adjust)? For the bottom fairing?

I have not been able to duplicate issues with the fairing on the MUS parts. They appear to keep the custom sizing (both major and fine adjust) just fine when launched/reverted/loaded.

Let me know if this persists with today's update, and I'll take another look over it.

Might also matter which part is the root part --- KSP has slightly different loading sequences for the parts, and there might be inconsistencies in how I am handling them / triggering updates.

It might be only when the bottom radius adjustment is set to zero. I'll test in an hour or so.

Okay, will test this out a bit myself and see what I can come up with.

Odd, now it's resetting to zero

But yeah, I can't replicate the original problem either, so either something changed in the last update or I'm just going crazy.

It does appear to have continued with the most recent update. I've also noticed it occasionally reverting on certain in-editor events, like attaching a part to the bottom node or even just opening the part action window, but I haven't isolated the circumstances under which that happens yet.

Hmm.. this one is indeed very strange.

After following your steps, I still could not get it to duplicate the problem; however, I did notice that it would occasionally revert to -one of- the previously selected diameters during vessel re-load; though not necessarily to zero or to the part diameter.

This all makes little sense; as the fairing itself is the only module that stores the fairing size, and I have a boolean flag in place to only do the fairing initialization a single time when the part is first selected in the editor.

Going to take another pass over the code though, as there must be some inconsistency in how it is initializing between the two modules.

Have adjusted the MUS fairing interaction code to not reset the user-adjustable fairing radius' except during prefab creation -- this should fix the problem of resetting fairing diameters on launch/revert/reload.

Should have this available with an update later today.

Still able to replicate with the SC-TANK-MU-ST: If tank radius adjustment is set to something other than zero but bottom radius adjustment is set differently, then bottom radius adjustment will be reset to tank radius in flight (and when reloading in the editor).

Okay, so... apparently this was related to a stale part.saved state data; I was not calling OnEditorShipModified when variables were changed, so the persistent variables were not saved.

This was also the cause for the inconsistent duplication of the problem -- if you made any other changes to a ship after modifying the size, they -would- save properly (e.g. adding/removing other parts, or even right-clicking or moving the part), and the problem would not manifest.