My understanding was that when the file /etc/passwd is modified, ... the change is propagated to the /etc/group.
It is not automatically propagated. It is perfectly possible to edit both files with a standard text editor (see footnote below), and create a variety of nonsensical situations.
I don't know enough about pw to be sure that is makes consistent updates to passwd and group files. The fact that it has both usermod and groupmod functionality makes me think that one can use it to change either file independently; I would check both files by hand after using pw.
(Footnote: After editing /etc/passwd, don't forget to update the database version that are actually used for login and process creation, using pwd_mkdb; or just use vipw to edit that file.)
So I was surprised, that this was not the case. Because it would suggest to lead the following scenario. Upon initial user creation, the numerical UID and GID are mapped on human-readable string. Then the /etc/passwd is modified, e.g., to change the GID, but if the change is not propagated to the /etc/group, the file would show a wrong user to GID mapping. Or, am I missing a concept again?
Yes, you are missing a concept.
Let's start with user Alice who has UID 1001, and at birth is put into group 1001, which is called AliceGroup. File /etc/passwd will contain an entry for username=Alice which says that she has UID 1001 and her default group is 1001. File /etc/passwd says that group 1001 exists, and is named AliceGroup. Perfect.
Now you go into /etc/passwd and change Alice's default group to 1002. Say for example that GID=1002 also exists in /etc/group, and is called BobGroup. This is not a mistake! It could be a deliberate choice: From now on, when Alice creates files, they shall be stored in Bob's group. That could for example be if Alice has been moved to Bob's project at work, and is helping him, so the files should be owned by him. So this mapping is not necessarily "wrong". The reason is that /etc/group does not contain the user to GID mapping; it instead has the GID to group name mapping (and a few other things that are not terribly useful, unless you are sharing data and the last column in /etc/group becomes necessary).
On the other hand, in a world where each user has a group of their own, and they are not shared, that setting is probably a mistake. But Unix itself can't know that. Both scenarios (Alice is legitimately in BobGroup vs. Alice should be in AliceGroup) can be sensible.
But the really important thing is this: None of this affects files and directories already on disk. Say there is a home directory /home/Alice, which contains lots of files owned by UID=1001 and GID=1001. If you change Alice's UID and GID entries in /etc/passwd and /etc/group, those files will continue to be owned by 1001. For example, if GID 1002 is named AliceGroup now, and a new mapping 1001 -> AaronGroup is put into /etc/group, then it will correctly say that the files in /home/Alice are owned by AaronGroup. The mapping that happens in the /etc/ files is independent of the numbers stored in the files and directories.