I'm not as familiar with the Debian/Raspbian bug reporting culture and attitudes as I am with that of Fedora, though I have bug reportings logins for both Fedora and Raspbian.
In your shoes I'd probably raise a bug on the grounds that if nobody raises a bug the package will remain uninstallable and won't get fixed. Then if I didn't want to wait for a fix to appear, I'd download and compile from source - and add comments to my previous bug if the source failed to compile.
I'm in a similar position with Audacity: the current version crashes if I try to record from an old Ion MixMeister ADC, and so does the previous (2.4.2 version) though both were fine in the past. The Audacity gang apparently don't have any similar ADCs so I'm currently helping to sort sort the problem out - bit of a faff since I'm not a fan of debuggers like gdb, preferring to work with run-time tracing rather than poring over crashdumps: when you've developed projects using standard languages (C, COBOL, PL/I) and standardish OSen (Unices, OS/400, VME/B), much more hardware specific kit like debuggers gets old fairly fast, but as always its a matter of horses for courses and YMMV.
The puzzle is _where_ to raise the bug. Starting from
it isn't at all clear where bugs should be reported. Almost like the Foundation doesn't _want_ bug reports. Part of the trouble is likely mixed parentage: RaspiOS is a Debian derivative, so who's responsible? There's no hint at raspberrypi.org.
I did try to download and compile xoscope 2.3 from github. It looks like the configure script fails. There's no very explicit guidance on how to specify an ALSA-compatible build, either. Since ALSA seems to be the only choice on the Pi that's a serious hurdle.
In the meantime it turned out that a build of xoscope on FreeBSD worked without a hitch; recognized the audio capture device and displayed reasonable waveforms. I will admit that the behavior of xoscope is somewhat obscure to somebody who learned about 'scopes on
500 series Tektronix instruments equipped with Polaroid cameras 8-)
At least there's a group of developers to help. Xoscope is much, much more obscure. But, you make a point, the program developers are maybe the folks who have the most interest in seeing things work.
I'll hold my peace for now, as I'm not sure xoscope will do what I want. It has the bandwidth and resolution needed, but triggering behavior is most confusing.
There does seem to be a "chain of command", in that Debian originates software, Raspberrypi.org modifies it and folks like me attempt to install and use it.
If I find something that doesn't work, is it my fault, raspberrypi.org's fault, or Debian's fault? First burden is on me, next seems to be raspberrypi.org and if they can't fix it the problem is Debian's. If Debian can't fix it the problem comes back to me.
In Debian, you would use reportbug. This is available on the Pi, and presumably has been tweaked to send the report to the right place. It isn't installed by default.
Everywhere a package is modified should be in the bug loop i.e. the Pi maintainers first, then Debian, then the mysterious 'upstream'. Whoever fixes the bug, if the bug came from further up the chain, will report it and probably provide a patch. If the bug comes from further upstream and is fairly fundamental, it will be passed up the chain.
Cough: ITYM Raspbian.org, since they own the OS and bug reporting system, although they're most likely to be the software part of the Raspberry Pi organisation.
That looks about right, though if it crashes on take-off without any Mayday message the finger points pretty directly at raspbian.org Similarly, my first port of call for anything in a package installed from the Fedora repository is the Fedora bugzilla regardless of who wrote and/ or maintain the packaged code. I think this is the usual and expected approach for most Linux distros.