I don't normally read forums as I prefer to spend my time developing rather than participating in hate speech (I'm a human being with limited resources, sorry). However, I've been pointed to this thread and I found some posts interesting enough to answer them in hope that my answers, as well as the answers of my fellow colleague Herwig, will eventually help people use what we (BWW) do.
First of all, Firefox install issues. The original issue of this thread's author was in fact not related to the RPM/ZIP war at all. It was just getting out of sync with announcing a new Firefox release and moving a couple of packages from the experimental repository (where all releases initially land) to the normal one. This happens sometimes and is usually fixed very quickly. Not a big deal. More over, in the future such issues will be resolved automatically (the technology we use allows to do that).
Next, about the ZIP installation of Firefox and its further support. As Dave already pointed out, we (BWW) discontinued support for ZIP installations. Back in FF Beta 7, by the way. The reasons behind this decision are described in README.OS2 (but who reads that, I know). In short, it's simply not possible any more. Some (actually pretty long) time ago we deliberately took the Linux approach of distributing software. This approach basically means that each and every 3rd party library any given software product uses is built as a DLL and distributed on its own rather than as part of that product and this distribution is then shared among all other products using the same library. The main benefit of this approach is that it greatly saves system resources (mostly in terms of occupied disk space and memory footprint) because programs share a single copy of the library code (and sometimes library data too). Another key benefit is that fixing a bug in such a library (and installing a new version of it) makes the fix instantly available to all programs using this library without a need to reinstall those programs themselves.
Saving system resources is what we need most from the new approach. While the available memory address space size is not a big issue in the 64-bit world, it is a very tight resource in the 32-bit world where OS/2 belongs (and will belong forever I suppose). I think everybody is aware about problems when several huge applications (be it FF + AOO + VBox) are runnig in parallel. You have to play with your VIRTUALADDRESSLIMIT setting in CONFIG.SYS and mark DLLs to be loaded high in order to make them work. And all these problems are about running out of address space because there are too many libraries used by these applications occupying too many memory pages and doing very similar things. Or, even worse, too many versions of the same library doing exactly the same thing but occupying as much space as there are copies of the library. And, due to technical limitations of the 32-bit world (and of the OS/2 kernel which is quite old and does not evolve) we, as developers, can't do much here. Except that we can try to eliminate similar or duplicate copies of libraries applications need at their runtime and this is what "Bitwise seems to like seeing how many dependencies they can make Firefox require" is exactly about. Reducing memory footprint. By breaking applications into as many separate and reusable pieces as possible. To let you run several modern and heavy applications in parallel. Or even simply run them at all. (It's not hard to imagine a single application that sucks in all available 32-bit address space).
Having so many dependent (and sometimes cross-dependent) moving parts, in turn, requires a decent software manager framework that can automatically resolve all these dependencies (including possible conflicts) and download proper versions of all necessary libraries — because it is simply beyond possibilities of a regular person to do it manually. For instance, Firefox currently requires about 50 external DLLs and a bunch of other stuff — this is NOT manageable by hand. DLLs required by Firefox have their own requirements, sometimes you need to take a specific version of a library and so on. And simply distributing all the required DLLs with the application inside a single ZIP is not a solution here, not at all. First, it will immediately create a well known DLL hell — the system will have many copies of the same DLL distributed with different applications which will be often conflicting with each other in many ways. Second, if you try to fix this DLL hell with LIBPATHSTRICT=T (which itself is a very dirty hack in the OS/2 kernel and doesn't always give stable results), you will completely beat the whole purpose of breaking applications into reusable pieces described above (and even the purpose of distributing libraries as DLLs at all). So the macOS-like all-in-one bundle strategy is not a way to go on OS/2. Needless to say that, having that many dependencies, even a task of bringing them all together (e.g. in order to pack in a single ZIP) or even simply mentioning them all in a readme becomes a big headache and this is why we gave up on this idea completely.
So, with the above said, we have what we have. RPM as the software manager framework, YUM as its command-line frontend and ANPM as its GUI frontend. RPM may be not the best software manager out there but it does its job (it was selected many years ago and we don't have resources to try out another one, at least not now and not in the near future). Actually, it's not that bad at all if you use it as it was designed to and not as you want it to use. This means that you should either install ArcaOS or properly install the RPM/YUM environment to your favorite OS/2 flavor and then only use YUM (or ANPM) to install all software that is being released as RPM (by BWW or any other party) even if there are alternative ZIP distributions of this software floating around. In this case, RPM will do all the dirty work for you. And it will do it right in most (if not all) cases. And if it doesn't, it's a bug that is about to be fixed. Don't get me wrong, when I said RPM is not the best package manager, I didn't mean WarpIn. Not at all. WarpIn may be younger than RPM, but it's so much behind it (or any other modern manager like DPKG) feature wise that it's simply not correct to compare them. In fact, WarpIn is essentially an installer, it has only very basic package management capabilities which don't meet the need of the real world — and this is one of the reasons RPM was ported to OS/2 in the first place. And while RPM has its flaws (e.g. some odd behaviour when resolving really complex conflicting dependency cases involving multiple indirect upgrades/downgrades), it's still much better than WarpIn and it's been serving such massive distributions as Fedora and CentOS for years which proves its stability and scalability. The mentioned flaws are rare cases that don't affect a normal user (and that are being addressed in DNF, a YUM successor that we will eventually port to OS/2, and in RPM itself). So, words like "a package manager from 90s" simply mean nothing. The whole concept of a PC from 60s and it still works pretty well.
Regarding language support and other reasons that could force you to use older OS/2 flavors instead of ArcaOS and eCS 2.x and hence have various difficulties with the RPM/YUM/UNIXROOT environment. This is an interesting point of view. But it is weak. I'm Russian. And I've been using English eCS for many years now. And I have Russian in all places I need. So I know what I'm talking about. Language support is not perfect but it's usable (and it may be improved). To put it simple, nowadays there is only ArcaOS. This is the only flavour which is alive, forget about everything else. ArcaOS is only English now, but there is nothing that would prevent it from becoming French, German or Russian — other than some reasonable amount of time and money. And you would better apply your energy in this direction instead of criticising a switch to RPM/UNIXROOT. Seriously. But even if, despite all reasons, you want to stick with some dead OS/2 flavour, there is still a solution for you: make some effort and bring RPM/UNIXROOT to your system. You may even do a package in your favourite format for that, be it ZIP or anything else, or improve the existing WPI of a standalone RPM install — as a courtesy to other folks using the same flavour. And we will even assist you, as time permits, if you file your problems in the respective tickets.
So, back to the Firefox ZIP distribution. Very soon there will be a Firefox RPM from BWW/AN that does all the dependency burden for you in one click. And there will be an automatically generated ZIP from us which is basically a repack of that RPM. There will also be an automatically generated list of required DLLs put into that ZIP, for your convenience. (This list is what you can actually easily get yourself from any RPM file by executing `rpm -qRp PACKAGE.rpm`). But not more than that I'm afraid. Everybody is free to give us suggestions on how to improve our automatically generated ZIPs or to contribute even further and e.g. write a script that converts our RPMs/ZIPs to WarpIn archives. (Or repack our software manually if you wish so). But it's clear enough that we have very limited resources and will not provide official support for a distribution other than our own RPM and our exact reaction to your suggestions is limited by our resource availability as well. However, it's never forbidden to ask us a question if you have one. Do it and chances are high that you get an answer. And, while ranting, flaming and hate spilling also cannot be forbidden due to a free speech principle, you will surely not get any answer on that

At least not from us. Thanks for your attention.