I can confirm this bug, thanks. I suppose in my own testing always maintained the default, primary group of users (matching the username) and instead had all additional group memberships be supplemental groups. After all, that means all files ever created by that user (even if not minecraft stuff) will then be owned by that group.
Of course, in the interest of actually working the way it should, it should accommodate the steps you describe, and I can see the issue is here: mineos/mounts.py at master · hexparrot/mineos · GitHub
It turns out that getgrnam() only returns supplementary groups and doesn’t return the primary, so it’s a relatively small fix. Seeing as how it’s python mineos, though, it’s TBD when things will ever change when it comes to lines of code that can adversely affect thousands of users (who don’t know how to roll back) but only potentially help small edge cases. I want this fixed, too, but without reliable testing help, this stuff always will take a bit to get implemented.