I've always been able to get away with a

MutableMap<String, MyValueType>

(or just

NbtTag

for the value type if you want to leave it open-ended). That might be an option depending on what you're doing

If you do want fine control over it though, it's pretty straightforward (just verbose) to create your own e.g.

MutableNbtTag

classes. I've got a good idea how that'd work if you want me to help with that

There was an issue opened about making

NbtTag

types mutable, and it's something I put a ton of thought into and don't plan on supporting for a few reasons. Mainly because I want to keep the scope of the library to serialization, so it makes sense to treat

NbtTag

as a representation of the serialized data (and serialized data is immutable). Plus that's the way kotlinx.serialization does it. There's also a lot of ways/assumptions in implementing separate mutable

NbtTag

classes which makes me hesitant to add them alongside the read-only ones in a general-purpose library like knbt (how copying should work, concurrency since the encoder assumes a lot about the data's immutability, ...). I think it makes more sense to leave it up to the person doing the serializing & avoid the added scope

If kotlinx.serialization adds mutable versions of

JsonObject

, and

JsonArray

then 100% I'll follow suit with knbt. I'm kinda curious of they have a rationale, and might be worth opening an issue if you want, even just as a question for the insight