If you create an NBT field that has a dot (.) in its name, it becomes inaccessible to any command that uses data paths, and can potentially create naming conflicts. Here's an example:

/data merge storage bug:example {object.value:"a",object:{value:"b"}}

This command does work, even though in this case, there seems to be a name conflict, because the path to both the "a" and "b" fields is exactly the same: "object.value". If you run this command:

/data get storage bug:example object.value

The returned value will be "b". Running /data remove with the same path will remove the "b" field, and running it again afterwards will fail, even though the "a" field also has seemingly the same path. It seems that the "a" field is completely inaccessible to data paths.

There's another bug with the /data command, where you can't clear a storage namespace entirely (you have to use /data remove on each of its top-level fields), and since the "a" field is inaccessible to /data remove, it's now permanently stuck there and there's no way to get rid of it using only commands, assuming it was created in the same way as the command above and not under another object.

Fixes for this might include adding support for fields with . in their name when using a data path (which sounds difficult), or just not allowing such fields to exist in the first place (which could break some existing creations).