There aren’t any immediate plans for a full-on serialization system. Even if there are serialization utilities added they would never be like Unity. Unity has an editor that maintains a huge database behind the scenes with all the assets, relationships saved, changes synced, etc. Nez will never take on that much control and force anything overarching on devs using it so it won’t ever be able to maintain that kind of information on everything from assets to scenes to Component properties.
Similarly, the Nez runtime will never have that kind of thing going on either. It’s made to be more simple and lightweight than that. What it could gain is a more simple system much like the Entity.clone method. It would basically funnel down calls to a serialize and deserialize to Colliders and Components. To make something like that fully automatic just isn’t possible. Extra metadata would need to be kept on things like animations, subtextures from GDX atlases, Nez atlases, TexturePacker atlases, etc, etc.
You can see how that could spiral out of control fast. And that doesn’t even touch on things like forcing Components to have constructors with zero parameters and custom classes. Having serialize/deserialize methods coupled with empty constructors would help but it wouldn’t be perfect.
What kind of system would work for your particular needs is hard to say. It would depend on if you are making an in-game level editor, simple game state save, detailed game state save, etc.