Right now, most per-player stuff is saved in separate Map<String, Thing>, where String is the player's name.

This is not only less efficient than reading/modifying a field in the player entity, but it also requires a lot more handling, given the maps have to be cleared when player leave, when being directly attached to the player would get GC'd automatically. Also needs to convert strings to player entities and back every time you try to do anything given the player entities are disposed when the entity dies, for example, so we can't rely on the entity instance or we would be creating a memory leak (like has already happened at least once).

My proposal is to add a new type, CarpetPlayerData, with the needed fields (or some more system to store info if wanted) that would be attached to players on initialization via a mixin, and would get reused when we know the entity is recycled. Ways to keep the data between sessions could be explored (such as storing them in a Map<String, CarpetPlayerData> that the player constructor (s) check when being created), but I don't think that should be necessary.

Accessing it would be simple, CarpetPlayerData would have a static method taking a ServerPlayerEntity (whatever it's called in mojmap) that would use an accessor and the necessary casts there (for convenience and as the more supported way, in case we end up supporting extension data there, see below).

Storing data for extensions isn't explored, but there could be some ticket system we could provide them that stores their data in an Object array, their ticket holding the index of their data, with methods to get and set.

Attaching all Carpet data via tokens would also aid compatibility for non-extensions, given some mods that modify the player list integrate with Carpet loggers via those player maps.

Maybe the same system from extensions could be used for Carpet stuff as well, given from some quick prototyping it's quite flexible and fast.