Is your feature request related to a problem?

Currently, OfflinePlayer#getPersistentDataContainer returns a immutable PersistentDataContainerView. I was wondering what concerns there may be for just returning a PersistentDataContainer and allowing plugins to edit data for offline players.

Describe the solution you'd like.

I'd like OfflinePlayer#getPersistentDataContainer to return a mutable PersistentDataContainer.

Describe alternatives you've considered.

I read over #8177, and the main issue with the original idea seemed to be that it'd be weird to handle nbt data for a player that hasn't joined. I have 3 ideas on how to implement this. (technically 2 as I'm re-proposing one of the old solutions that didn't get commented on)

Firstly, just return null if the player hasn't joined before. Mention it in the docstring that if the player hasn't played before, then the returned value will be null. This was proposed in #8177, but was not commented on.
Secondly, add a tag like "hasPlayed" that maps to a boolean. Logic based on the existence of the data file (like OfflinePlayer#hasJoinedBefore) will just read that value.
Thirdly, If the main data file doesn't exist, save data to a .prejoin.dat file. This file would contain all the data for a player until they join, at which point the .prejoin.dat file would be merged with the main data file. After that, all future edits will just go to straight to the player's data file. This prevents any logic changes based on whether the file exists.

These solutions handle what to do if you don't want to allow editing the nbt data of players who haven't joined before, as well as what to do to prevent/address any logic errors based on the presence of the .dat file.

Other

No response