For automated install users, it's nice to provide a command line version of install that expects no user feedback in any form. Usually this is trivial for the developer to do.
Not fully possible, because I have no way to assign nor test 80x08 icons, and the installer requires a third-party utility.
An alternative, which I'm using, for a BEEP and return code 7 is to optionally repackage FF/SM/TB with DLLs marked as > 512 MiB and with a matching *TURBO.EXE, to distribute other qualifying LIBPATH DLLs marked as > 512 MiB, and to create the 3 WPS programs objects with an own SysCreateObject() install script in folders of your own choice.
Presumably the install works, so e.g. checking DLLs shouldn't have an added value.
A recent change is that more DLLs (NSS/NSPR) were added to a list of "approved" DLLs. Such an event may be less trivial, compared to shipping a more generic update of files (e.g. a CMD batch file which just successfully marks NSPR4.DLL as > 512 MiB). Actually my next "internal FixPak" includes doing just that, without updating the whole packages.
It could introduce an own standard EA too, to avoid that an automated installers marks the same DLL twice. If all DLLs are already marked, themn an automated installer shouldn't beep when HIGHMEM.EXE is missing.
Finally members of the product family (FF/Mozilla/SM/TB) itself have no guaranteed automated installer. I could order a virtual system with eCS 1.2 NL, which typically will only include Mozilla with an outdated MOZTURBO.EXE (i.e. not Dave's) which may produce SYS2070s. So even then you may have to update MOZTURBO.EXE afterwards.
There is no need to advocate an automated install option as such, trivial or not, and in general it's worth being kept in mind, but I'm not sure what the added value is when an alternative is to distribute fully updated DLL files and to create 3 WPS objects by yourself (excluding the installer/uninstaller). For a single install the installer has an added value, due to checks, taking care of read-only settings, marking DLLs, and so on.
Indeed changing the default WPUrl browser settings via changing OS2.INI does touch the system, but even then it may be better to write an own script which sets those probably fixed settings (fixed per browser) in an early phase of a full install. Because it may not be the only "fix".
Nevertheless I can change a generic default browser selector to include support for arguments, so that becomes an automated installer. If so, with or without showing an error message (file not found, directory not found)?
In this case I'm not sure what the added value is. You'll have full control when you ship DLLs already marked as > 512 MiB, which almost reduces the added value of the installer to a common WPS object creator. Which has to be executed in the right environment. With an own alternative you can even move the *TURBO.EXE files to an own directory, without Dave's (implied) defaults (like the *TURBO.EXE in the main directory of the Mozilla product, and no support for the turbo's directory parameter). Point taken, but are you sure that an automated install option has an added value compared to the alternative? In this case you can distribute repackaged marked files, and you may have to append 2 SysCreateObject()-lines, 1 SysCreateShadow()-line and 2 SysIni()-lines to an own Rexx install script.
I'm not using automated installers that frequently myself, but I cannot recall any glorified WPINSTALL.CMD which requires a third-party product (ABOVE512.EXE or HIGHMEM.EXE) anyway, but only during the install.The installer could try to find ABOVE512.EXE or HIGHMEM.EXE, which may take a long while when a customer has 26 drives including a few slow, TiB-sized ones. If you ship patched DLLs, then you can always skip this too. Then it's always just a glorified WPINSTALL.CMD.
In the case of a single user with a limited number of old or new installs the added value is more clear. Once you got it right, it's quite easy to copy and reproduce such a working and verified install.