Thank you Jon for taking the time and effort to give a comprehensive answer. :) Honestly, this is what I expected and I won't question the priorities set by WMF. I'm just looking into how the UploadWizard project could be continued in the future, and with what parties involved.

Would it make sense to create a community-maintained fork of UW that would ditch Commons-specific features such as structured captions? IMO there's enough third-party interest for this to be viable and a fork would have two major advantages. First, there would be no need for WMF to be involved, so the extension could be developed at its own pace, independent of Wikimedia's strategy and work allocation. Secondly, Commons has a very large number of specific requirements that make adapting the tool to be usable by both it and third parties a rather difficult task. An example of this are image-based tutorials that are very hard to maintain, especially for small communities. Features related to Structured Data are great, but completely useless for third parties. I also wouldn't be surprised if Wikibase integration becomes stronger in the future and some other parts of the wizard could become redundant for Commons. In such a case, with a community-dedicated fork, WMF could have greater freedom when it comes to cutting features it doesn't need anymore. That last part is pure theorizing, though. :)

IMO, in this case, the potential benefits coming from making a fork outweigh the disadvantages. I see two different sets of requirements and the division between them is likely to only increase in the future.

If we were to make a fork, I have an entire backlog of features / fixes waiting to be implemented. Some of these stuck in review, some were already started, and others have been patched haphazardly locally in the past, so it's not starting from absolutely nothing. The things that I have on mind are:

• Rework config handling to make it more consistent (now only campaign configs are parsed, the main config is not) and robust (unit testing included!).
  
• Simplify the task of including more licenses in UW (message loading based on config), add more built-in icons to make that even simpler for site admins.
  
• Change the tutorial from an image to wikitext, which should be much easier to edit.
• Restructure documentation to be third-party centric, maybe make a brief configuration guide (configuring UW now requires one to carefully study a not-so-friendly PHP file).
  
• Add a few quick hacks to make the UI responsive, at least to some degree (that is very much possible with just CSS). The solution can be polished later.
• Remove Wikibase-related code and other Wikimedia-specific stuff that will just make testing harder.
• Improve configurability for all fields in the wizard, ensure sensible default settings.
• Add an option to use single-language fields. Multi-language fields are unnecessary on most wikis.
• Look into how different stages of UW could be streamlined / improved to make the upload process faster, especially on wikis requiring less detailed information.
• Make all kinds of file description syntax configurable.
• (Maybe) prepare and package a few ready-to-use configuration sets, together with the templates necessary to make it work. That would really simplify the process of bringing UW to a wiki.