Process plugin issue when destination and source field share the same name

Problem/Motivation

This problem occurred when I created a custom migration, using "core/modules/user/migrations/d7_user.yml" as starting template. I noticed that one of my fields was always handled through the default "get" process plugin, no matter what I entered in the process mapping. Through trial and error I found that this only occurred on fields that had the same name in both the source and destination.

After debugging, it turned out that the set process plugin was always overridden during field discovery (see addBundleFieldProcesses in "core/modules/migrate_drupal/src/FieldDiscovery". I am not sure if this is normal, but I noticed a lot of seemingly unnecessary loops, where Drupal kept mapping the same process plugins of all fields, while going over individual fields.

What also seemed strange was that process plugins were determined for the source fields (which usually resulted in the standard "get" process), which is what causes an issue at the end where you end up in the "core/modules/migrate/src/Plugin/Migration" mergeProcessOfProperty method with all correctly mapped processes in $current_process and the resulting second array for the mergeDeepArray method containing only a single entry: the source field with the same name, which is mapped to the "get" plugin. Which then overrides the correctly mapped process field in the $current_process array.

Steps to reproduce

1. Create a migration that uses the "Drupal\user\Plugin\migrate\User" class
2. Add processing for a user field with the same name in D7 as in D9
3. Use any plugin except the default to process said field. It will ignore this config and default to "get" every time

Proposed resolution

It seems to me that there is something wrong with the way the process plugins are currently mapped, seeing as there is so much repetition going on.

A possible solution seems to be to not map process plugins for source fields, since this seems unnecessary (unless there is a specific reason for this).