This is more of a discussion topic than a bug.
We use Oauth2 custom provider (we have our own Oauth server) for authentication. This server has always the latest and true data about users (name, lastname, internalid, email etc).
I'd like our moodle to use this data about users, so I set up user mappings - everyhing works great.
One day I discovered, that some of the students are not enrolled in the course. This course enrolment is based on their internal id which comes from the Oauth2 server. I discovered, that this particular student accidentally changed this internal id in his profile.
Anyway, I locked all mentioned user fields in Oauth2 plugin, so that user cannot edit them. This way, students are unable to change their internal id and they're able to change other profile data, which are not synced from Oauth2 server - great.
Seemed like a problem solved until one of the students changed his/her name. This name should be propagated from the Oauth2 server to Moodle, but based on the code in auth/oauth2/classes/auth.php:

// We should update fields that meet the following criteria:

            // - Lock value set to 'unlocked'; or 'unlockedifempty', given the current value is empty.

            // - The value has changed.

            if ($lockvalue === 'unlocked' || ($lockvalue === 'unlockedifempty' && empty($oldvalue))) {

                $value = (string)$value;

                if ($oldvalue !== $value) {

                    $user->$fieldname = $value;

                }

            }

that field does not get updated!

To me, this does not make much sense. Why would I create user mapping if fields are then not updated? And on the other hand why would somebody want these synchronized field be editable by the user in his/her profile (especially if they are updated back on the next login by the Oauth2 server)

IMHO, there should be another check in the code snippet above which enumerates all the fields in current user field mapping and if the field is present in the mapping and it's value has changed then it should be updated.

I'm not sure if this is the problem of just the Oauth2 plugin or any other auth plugin with the same principle (eg. external server provides relevant and truthfull data about the user)