As @gaborrell pointed out in #4, the index.xml for QuietComfort 35 II (BayWolf) from downloads.bose.com contains not just a stack_plus_app.dfu but also two .xuv files, ext_signed.xuv, and acorn_coeffs_signed.xuv. Upon further investigation of the archives in bosefirmware/ced, it seems like my device, Foreman, is coincidentally the only one that doesn't have updates with at least one .xuv file.

These .xuv files contain binary data in a rudimentary address+data ASCII hex encoding. The "ext" files are particularly interesting: once decoded back to binary, they begin with fsr_dfu1 magic, which also occurs at various points inside the .dfu files. However, the data following that magic in a given ext_signed.xuv file does not also occur in the corresponding stack_plus_app.dfu file, and in at least one case the former file is larger than the latter, indicating it's an independent piece of the firmware that also needs to be flashed.

Reports indicate that flashing the .dfu file alone seems to work and change the indicated firmware version even for devices that also have .xuv files, but if the two are truly multiple pieces of one firmware image, there could easily be functional issues that occur when they don't match.

To investigate these files further (and hopefully support them properly in bose-dfu), I'll need USB captures of the official updater updating any device that uses them (i.e. any device except the SoundLink Color II). You can gather this with Wireshark (make sure to install USBPcap during installation). If anyone could gather these and share them privately, I'd be grateful! If you filter your capture before sharing it, ensure you don't inadvertently filter out any packets going to your Bose device. The capture should have packets going both to and from the device in both DFU and non-DFU mode.