I think it might be good idea to integrate this lib with configurate project. Configurate is an open-source configuration library developed by Sponge team. Some good bukkit-based engines like Paper is already using configurate. In my opinion it may replace the old bukkit configuration system. Link to the project: https://github.com/SpongePowered/Configurate.

The nbt structure could be converted into a configurate node and vice versa. It would create an opportunity for powerful NBT-based serializers for entities/block/item data. For example:

Let's take a hoe with unbreaking III:

Bukkit representation:

==: org.bukkit.inventory.ItemStack
  type: STONE_HOE
  amount: 1
  meta:
    ==: ItemMeta
    meta-type: UNSPECIFIC
    enchants:
      DURABILITY: 3

It is not very intuitive, because end users are more sticked to minecraft naming, not bukkit naming.

NBT String representation

item: '{Count:1b,id:"minecraft:stone_hoe",tag:{Enchantments:[{id:"minecraft:unbreaking",lvl:3s}]}}'

It is intuitive, because it uses nbt and minecraft naming, but passing everything as nbt string in yaml file is half-soltion.

NBT converted to configurate node:

item:
  Count: 1
  id: "minecraft:stone_hoe"
  tag:
    Enchantments:
    -
      id: "minecraft:unbreaking"
      lvl: 3

And with help of Configurate's Object Mapper this complexity can be acomplished with simple:

@ConfigSerializable
public class Config {
  
  private ItemStack item = Items.DEFAULT_ITEM;

}

at the developer site.

Configurate is very powerfull. The only thing to implement is the way to change a NBTCompount into ConfigurationNode and node to compund. It has not to be a major funcionality, but only a minor feature. The next step is to add some usefull serializers for think like ItemStack in the example.

I don't think this can/should be added into the current NBT-API due to adding more dependencies. Currently brainstorming ideas for a 3.0 version that probably will be maintained next to the the current 2.x version due to having different goals:
2.x:

• be shadable
• work with 1.7.10-newest release
• provide a basic wrapper for the NBT Objects
• Stable API

3.0:

• Full plugin, so no shading(allows me to go more wild with dependencies/use of the Spigot/Paper API)
• Only target the new-ish versions, so it can use Java 9+ features
• Base on Paper instead of Spigot?
• Focus on developer comfort by providing a lot of utility(like this issue)
• Also a bigger focus on performance compared to 2.x

So I'd say this should be a 3.0 feature request.

While Configurate is neat, I doubt NBT-API 2.x would benefit from it.

Shading it into core would add a few extra hundreds KBs for something that the majority won't use.
This will make the lib even less lightweight, and there might be a few caveats for devs while using the shaded version instead of, for example, Paper's built-in one for their own needs.

And the standalone plugin needs only like 4 booleans for the whole config, so I think it's not worth it either.

I'd be all in for using it in 3.0 though if we drop Spigot support and switch to Paper while focusing only on the newest versions (using all the neat stuff like Configurate/Adventure/etc.). Though in the latter case Hangar opening would be nice in order to have SpigotMC alternative for Paper.

Edit: this actually might be trickier considering 3.0 targets supporting multiple platforms, not just bukkit-based ones.

If your plan is to make the NBT API lightweight it might be really an issue. There is also a different way. NBT - Configurate mapper could be added in different module, so if someone would need it they could take only what they want. I also understand it might be an overkill to bring an own module for suach a small feature, so I will not be disappointed of denial.

It's all a bit tricky. On the drive home from uni also thought about having 2.x inside 3.0 as a fallback/to provide its usual classes, but that also opens a fun can of worms in regards to class versions. If the 3.0 plugin replaces the 2.x plugin for end-users(which would simplify it for them), then the Spigot main class needs to run under Java 8, while most of the rest is compiled for Java 16+. Will require some more brainstorming. About the platform stuff and extending NBTCompount, I think the cleaner way is to have a wrapper that can translate NBTCompounds to ConfigurationNode's on the fly. The same logic(also in reverse) could be applied to other config and data storage classes.

Closing this issue. Don't think there is anything here to do really? Usually, you want to store stuff in the string representation, converting it to another format is a bunch of work for no gain(just eats performance), and potentially causes issues as with 1.20.6.