Under RetailSDK\References are the DLLs one has to add to commerce.runtime projects. to get to these DLLs one has to select the folder the specific DLL is in. However these folders names changes with every month's standard application and platform upgrades. This results in breaking custom CRT projects that worked just fine before the standard upgrade.

E.g. Microsoft.Commerce.Runtime.Entities.DLL
In v10.0.6 to get to the above DLL, one has to select the path:
RetailSDK\References\Microsoft.Dynamics.Commerce.Runtime.Entities.9.16.19332.1\lib\netstandard2.0\Microsoft.Dynamics.Commerce.Runtime.Entities.dll"

In v10.0.7 for the existing CRT projects that references this DLL , the references inside the project isn't working anymore because after the upgrade it doesn't exist. One needs to then delete all the broken references and re-add them. for the above DLL, it needs to change to:

RetailSDK\References\Microsoft.Dynamics.Commerce.Runtime.Entities.9.17.19348.3\lib\netstandard2.0\Microsoft.Dynamics.Commerce.Runtime.Entities.dll"

Under "K:\RetailSDK\Update" each version is already identified by a GUID to make it unique. No need to have the DLL sub-folders also to change.

If I have to manually change the names of those sub-folders, I run the risk to break standard setup. If code is locked down, so should the directory structure and I should not need to be expected to change standard setup to get my extensions to work every time after an upgrade.
Upgrades now happens once a month. It is a lot of extra work to keep on changing perfectly good code because the Microsoft upgrade broke it.
Those sub-folders aren't added manually. It is a process that generates it and adding that code as part of the naming convention. So it should be a lot easier for Microsoft to make the naming convention static for the References sub-folders.