Thanks for your explanations concerning the standard tools' IDs. The fact is that I have never been able to use any of the standard tools as they are. I have always had to create custom ones to fit my needs. In any case, the manual (on which my assumptions were based) would need to be updated, or at least the examples it provides. For instance, on page 177, one example of a command-line is:
PDFXTools.exe /RunTool:showprog=no;showrep=no imagesToPDF "c:\picture1.png" "c:\picture2.png"
This could be corrected.
That said, I have no problem with GUIDs as such, except that they are not portable. You ask what special use I have for non-GUID names. I do precise analysis, standardisation, reformatting and restructuring of large PDF libraries in order to improve their accessibility and usability. To this end, I have designed a number of home-made utilities written in various scripting languages (Lua, Python, AutoItScript) which call specialised command-line tools (mostly PDFTools, Coherent cpdf and pdftk). All these toolds are portable, except PDFTools, because of its use of GUID-based identifiers. So, for the time being, your software is installed on my laptop which I have to ferry around with me to the various places where these libraries are stored and, each time, establish some sort of network connection with the computers hosting these libraries. It's manageable, but very inconvenient,
So I am thinking about the future. It would be much more convenient to have a portable version of PDFTools which could be carried around on a USB stick, together with the other command-line tools and utilities mentioned above, to wherever they are needed. The problem, of course, is that GUI-based identifiers are tied to a particular machine's registry, so cannot be portable. Hence my suggestion.
Of course, I agree that GUID-based names are reliable. But it seems to me that, on balance, the "cost" for this reliability is disproportionate. Surely, you keep a dictionary of the custom tools' names created by the user within some internal database, together with their definitions, for each instance of PDFTools. Wouldn't it be simpler and just as reliable to test the uniqueness of a custom tool when it is created. Or am I missing something?
I would add that, based on a long experience of Windows, I find that Microsoft's use - and abuse - of the registry is a source of instability and security leaks which is not justified by its obvious advantages.