Apologies for my (newbie) comment on this bug reporting system. Since I have a screen shot bitmap better showing error I described, could anyone tell me how to attach to this bug ?

In the editor you find a cloud symbol with an arrow to upload a file. Use this and and the file id will be pasted at the cursos, like here

My apologies for further delay before also providing this screenshot bitmap of error found (because of initially not finding specific site info about best browser to use and not seeing 'cloud symbol' (many thanks werner :-D ) I obviously had to switch from IE11 to MSEdge and then also manually import proper cookies needed for this site :-(( )

Woops, :-s I forgot to also add all these details from additional investigations I already did (obviously assuming it might be helpful ones for definitely fixing issue I reported (and my apologies in advance for whom might find lenght of all this really excessive, 8-) since I simply tried to comprehensively summarize results...)

Size of system %PATH% variable (for %PATH% I mean excluding 'PATH=' initial characters) in my own environment when I 1st ran 'gpg4win-3.1.16.exe' setup as an admin was initially 3086 characters(=bytes). After what happened I decided to manually review its contents and after determining it contained errors (=duplicate paths intended as unneeded repetitions of same path) I manually corrected them into registry, lowering its size to 2536 characters(=bytes).
But by doing this I was too fast and forgot to follow standard official way (so via Control Panel -> System -> Advanced settings -> [ Environment Variables ] ) and that resulted in unexpected restart of Desktop .
However after that I verified that only new Desktop (explorer) session inherited updated new %PATH%, which I also ensure it was automatically updated even more (after I manually removed another application owning first folder path found into %PATH% and then added back same app but with more updated version whose number is also into its folder path, once again at beginning of updated %PATH% contents).
Also, because explorer session I used when I ran 'gpg4win-3.1.16.exe' setup as an admin for the 2nd time (to finally take screenshot I already published here) is a 'separate' one, it didn't inherit any updated %PATH% contents and so I fully reproduced same initial situation (while I was wrongly a little expecting this not to happen).
Anyway, after doing all this, I also investigated some more about expectable maximum PATH size, and found these known references from MSFT :

• a quite old KB article with title 'Error messages after you change the 2047 character limit in an environment variable on a computer that is running Windows Vista, Windows 7, Windows Server 2008 or Windows Server 2008 R2' referencing a post SP1 (March 2012) fix that expanded:

"maximum length of an environment variable" "...increased from 2047 characters to 4095 characters, and you can enter 2047 characters in an environment variable in the Environment Variables dialog box. In the Environment Variables dialog box, the maximum number of characters that are displayed is 4095. If an existing value contains more than 2047 characters, you cannot enter additional data. However, you can delete the characters that are displayed. If a system environment variable is set to a value that is greater than 4095 characters, only the first 4095 characters are displayed. In this situation, when you click OK, the value is truncated permanently to 4095 characters, and the value is updated and stored in the registry."
(to me this might also mean that 'gpg4win-3.1.16.exe' setup may likely even have checked %PATH% lenght was over 2047 characters when it displayed error 'PATH env variable too big');

• another little less old KB article with title 'Update that enables you to upgrade from Windows 7 to a later version of Windows' also confirming that same fix, even more updated, was spread (end of March 2015) even more since it became part of components needed before start of Win7 to Win10 free upgrade timeframe,
• another reference to another old known KB article with title 'Command prompt (Cmd. exe) command-line string limitation' also confirming possible correlations among CMD command prompt and "... maximum length of the string that you can use at the command prompt" that "...is 8191 characters..." for "...computers running Microsoft Windows XP or later..." and also that same "limitation applies to the command line, individual environment variables (such as the PATH variable) that are inherited by other processes, and all environment variable expansions. If you use Command Prompt to run batch files, this limitation also applies to batch file processing."
• and then also some more additional references for more general Win32 related topics (1st from last mentioned CMD related article) about "SetEnvironmentVariable function" originally from MSDN site but now moved into MS Docs site , about 'Changing Environment Variables' and finally 'Environment Variables'.

Because of T3458 and other references to PATH I found in the past (see past references I added previously into this bug), could anyone please be so kind to confirm me if am I right to assume that under normal conditions (so with no PATH related errors like 'PATH env variable too big' I reported here) after proper end of 'gpg4win-3.1.16.exe' installation only following (unquoted) path string 'C:\Program Files (x86)\Gpg4win\bin;' would have been added at beginning of PATH system environment variable ?
Or if not, would new path rather have 'C:\Program Files (x86)\Gpg4win\bin;C:\Program Files (x86)\GnuPG\bin;' (always unquoted) prepended at beginning of PATH system environment variable ?
P.S. Please note that I'm only asking this to then try to properly manually set PATH system environment variable accordingly and then see if my (current) 2nd 'gpg4win-3.1.16.exe' installation can still work correctly as expected or not... ;-D

OK, while I'll be awaiting for anyone to possibly answer my last 'Sat, Sep 18, 6:29 PM' question that I decided to re-update today, just for sake of completeness I've also been able to check more inside registry but details will only go inside T5605 since only pertinent there ;-D

While I'm still waiting for anyone to possibly answer my last 'Sat, Sep 18, 6:29 PM' question I've also added there the explanation behind that question... :-)

@swimmerm, look at the files installed in both dirs.
There is no gpg in %ProgramFiles(x86)%\Gpg4win\bin, it is in %ProgramFiles(x86)%\GnuPG\bin.
On the other side, md5sum and pinentry are in the first one.
So, I believe you (and I) should add both dirs to the path.

UPD: It happened that I still have one cmd opened before Gpg4win update, so it still has old PATH env var populated.
In previous version %ProgramFiles(x86)%\Gpg4win\bin was not in the PATH. Only %ProgramFiles(x86)%\GnuPG\bin.

BTW, there are known solutions to manage with PATH overgrowth.

On the issue, I think there are several possible solutions, better than current:

1. Warn user that PATH is too big and tell him which dirs should be added manually
2. Warn user that PATH is too big but still modify it. He has to modify it with something else than UI, so it's for expert users only
3. Ask user to choose between 1 or 2

I'd choose 3.

@grv87 OK, many thanks indeed for confirming all this.
About your 1st comment: that's just right why I asked about it. Regarding md5sum and pinentry both must be the reason why now they decided to also add 1st path into environment while in older version wasn't there. Main issue is that because of the quite generic 'PATH env variable too big' error so far we can only assume 2047 was indeed maximum size for %PATH% Gpg4win developers have been expecting so far, while after that change from March 2012 QFE fix a definitive fix to implement in setup and rest of Gpg4win involved code will just be to enhance that maximum allowed path size to 4095 characters (BTW also checking anyway for size of %PATH% already active before setup will continue with new %PATH% changes is probably best option too).
About your 2nd & 3rd comments: thanks for those useful references. Would probably be quicker to implement, but it's still again true that maximum size expected for %PATH% will still need to increment from (likely) 2047 to 4095, plus also what you said about something "for expert users only". And even then inside README.txt (that now corresponds to %ProgramFiles(x86)%\GnuPG\README.txt or %ProgramFiles(x86)%\Gpg4win\share\gpg4win\README.en.txt or %ProgramFiles(x86)%\Gpg4win\share\gpg4win\README.it.txt) there should be at least 1 note about suggested way to do things. Problem is that because of above (March 2012) MS KB article statements '... If an existing value contains more than 2047 characters, you cannot enter additional data. However, you can delete the characters that are displayed. ...' whenever %PATH% size is over that value (always true for me even after manual %PATH% downsizing I had to do) OS UI will be of no or very little help (and by very little I intend that to overcome that OS UI limitation expert users with Admin privileges will 1st need to manually modify Path value into Registry, let's say by adding at least 1 or 2 ";" really unneeded, then just use OS UI to modify %PATH% system variable by deleting those ";" unneeded (i.e. %ProgramFiles(x86)%\Gpg4win\bin;;%ProgramFiles(x86)%\GnuPG\bin;;) and then once removed confirm with OK twice, and voilà it's done).
(P.S. BTW I just checked that so it really works fine for all applications started after that change ;-D so this might probably be best known option to document inside that README.txt.
N.B. JFYI in the past I also tried to use SETX from command line, and so I discovered that it only has a 1024 maximum characters limit after which it will just truncate any expected change that is saved anyway into selected system variable).
Otherwise, another possible approach variation but unsure if needing more coding would be to create 2 new system variables (let's say Gpg4win and GnuPG) and then add both %Gpg4win%;%GnuPG%; in front of existing %PATH% while installing, but obviously still after enhancing maximum allowed PATH size to 4095.

@swimmerm, my 2nd comment offers some solutions for you and other users coming here with the same problem with their PATH. It should be done on user side. I don't offer to implement this in Gpg4Win installer.

Referencing one env var in another doesn't work reliably with all software. For instance, here is algorithm implemented in Windows Terminal. They specifically say that environment variables from registry are loaded in arbitrary order. And there are no forward declarations for env vars.

@grv87, thanks for clarification (and very interesting side thread reference you gave, indeed, also because it also gives you an idea of how system environment changes during OS startup). I precisely see your point and that's also why I said "create 2 new system variables".
I've not said this very explicitly before but for that I also meant to just create them during Gpg4win setup. When it is run, I assume we can also say that OS system environment is already in place and %PATH% should already be stable enough to consider that as a good starting point to add things. So once you can really do that (I mean add 2 new system variables), and then also ensure they're created correctly, then I can also assume that then starting to use them to update %PATH% system variable might be fine too.

Could anyone please be so kind to confirm me if when 'gpg4win-3.1.16.exe' setup completes without any error the new folders where Gpg4win and GnuPG commands can be found are prepended (so inserted at beginning) or appended (so added at the end) of already existing %PATH%) ?
I'm asking this to properly ensure that my new manually modified configuration %PATH% is indeed equivalent to an original configured one (and so far I've assumed that my manual changes should have been prepended %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin;%PATH% but doing this was probably only my choice because such changes were just faster to do).

Many thanks in advance.

Caveat, Caveat (Warning, Warning) I know I've been quite busy with other activities, and ITMT my client status went really bad and even worse reached its final point and self-rebooted while I was trying to suspend it, but anyway this update is needed because I just discovered that my last choice to prepend %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin;%PATH% was not very good. Why ? Simple, as I discovered today (few hours ago) using this syntax, will only be valid&useful only if you really want to restrict Gpg4win v3.1.16 usage only to accounts in Administrators group.
Ok, so now you're wondering: How I discovered this effect ? Again simple, desktop shortcut that I have for starting new 'Command Prompt' was modified to always run as Admin, so I have to specifically choose when I want to run it without Admin privileges, and so today, after I didn't notice I had launched Kleopatra before, right after closing it, I launched a new Command Prompt and so when I tried to run 'gpgconf --kill gpg-agent' I only received this answer :

'gpgconf' is not recognized as an internal or external command,
operable program or batch file.

So then I obviously opened another 'Command Prompt' as an Admin and correctly killed gpg-agent so ensuring that everything was indeed still working as expected.
So now you're asking, why in the past I had confirmed that prepending those paths I was expecting to work, really worked ?
If you remember well how I reported Iìve done my past installations and tests, I also made those changes in OS System Environment Variables really on the fly and then just re-confirmed they were valid via GUI by simply pressing [ OK ].
And so this is the test I just repeated again and so I can re-confirm you that only after by doing so, every new 'Command Prompt' started as non Admin user will have proper access to those newly prepended paths.
Otherwise, those paths will work only for any new 'Command Prompt' if run with an account in Administrators group.
So while this can still be temporarily fine for me, I'm unsure it might have been a real standard choice for Gpg4win v3.1.16 setup run without experiencing the error I'm reporting in this bug, so please just ensure to avoid using %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin; syntax when changing your paths on the fly by prepending it or appending to %PATH% even if you should try to definitely solve same error I found and reported with this bug. OK ?
Thanks for your attention (for now).