Entities immediately become dry when they are unloaded, such as if a player moves far away, the server restarts, or a singleplayer world is closed. Reproducing the issue can be a bit tricky due to the need to unload chunks with deliberate timing, so I built a world with a simple mechanism to test this. I also recorded a short video of myself using the mechanism to demonstrate the issue, in case that would be more convenient than downloading the world and using it yourself.

Recording: https://user-images.githubusercontent.com/49110090/151140675-b44924e7-98da-43e0-81ba-da8cd036dab8.mp4
World download: EnhancedMoistness Testing.zip

I don't imagine that a log file would actually be very relevant to this, but here's one anyways: Link

One of the big reasons I'd love to see Moistness as NBT data is actually so that I can then check for it with other mods' scripting systems, such as KubeJS and Figura. It'd be neat to be able to make playermodels that can react to getting wet, or KubeJS models that can add custom functionality for Enhanced Moistness :)

The wetness state not saving is intentional as it's a transient state and is unimportant to keep across chunk unload/load.

Would break vanilla compatibility since data would have to be replicated to clients

No, just adding something to server-side NBT doesn't break vanilla compat. Adding a field to the DataManager would, however.

it looks like isWet isn't actually overridden on the client?

It is, but it's not synced from the server. Syncing this from the server is possible but kind of a hassle, and would generate a lot of network traffic. If I did this, I'd want to have something in base Fabrication to justify it instead of it just being a dangling hook for a Figura model.

A more obvious indicator an entity is wet would be nice, so maybe wet entities could be made slightly darker...?

it looks like isWet isn't actually overridden on the client

i am deeply unfamiliar with anything post zenscript (exception being fscript obviously)
but since isWet can be read server-side could you script it to write to nbt / sync somehow?

Would break vanilla compatibility since data would have to be replicated to clients, especially if you want to be able to use it with other mods.

Could potentially be considered for Fabrication X?

other mods' scripting systems, such as KubeJS and Figura

do they not hook into isWet in any way? L78

Ah! Thank you very much for reminding me of that function, somehow it slipped my mind that the function would still be overridden when called by a script. Took a bit of hunting through mappings for KubeJS, but it turns out it and Figura do both have a way to call isWet and it works perfectly. :) Thanks!
(Wait, actually, interesting update on that - it looks like isWet isn't actually overridden on the client? Should I open a new issue for this?)

It is, but it's not synced from the server

Ahh, I see, I was thinking that both the client and server were independently tracking wetness so that the client could do the particles/sounds, and the server could do Impaling, fire extinguishing, etc - it hadn't occurred to me that the server can just tell the client to do the particles/sounds, although now I realize that that's how it'd have to work in order for vanilla clients to get the effects. Although having the client also independently process wetness would let it use that data to use for a fancy new visual indicator, without the need for any syncing, right? I don't know exactly how reliable that would be, though.

could you script it to write to nbt / sync somehow?

That'd definitely be possible for KubeJS, although Figura runs exclusively on the client, so playermodels wouldn't be able to access that unless a server-side KubeJS script is storing it in NBT for Figura to use.