The closest you’ll get of having a compatibility list, apart from reading the code in the sound/ subdir in the kernel souce, is the aforementioned ALSA page https://alsa-project.org/wiki/Matrix:Main
If you’re having problems with the card on Mac as well and also have seen forum posts about it having driver issues on Windows then it’s not the Linux devs’ fault if it doesn’t work the way you want it to.
That said, this post indicates that it has at least basic functionality right now. And with a bit of luck Geoffrey will have a driver for the software side within the foreseeable future. https://linuxmusicians.com/viewtopic.php?f=6&t=20669
Here’s his Ardour post regarding his previous Scarlet driver
Reverse engineer firmware upload protocol and communication with the firmware
Reverse engineer the firmware
(1) is feasible, using some USB sniffer
(2) will be hard to near impossible, most likely this is a FPGA netlist and/or some SOPC binary
In many cases there are plugins (usually VSTs) that provide an equivalent to the DSP that (2) does. This way you can use the same FX for zero-latency monitoring in hardware, and later use the same FX when mixing in software.
Usually that VST plugin also directly interacts with the device to keep settings in sync.
A practical issue with (1) is that when Linux uses the device as soundcard, it is “busy” (device in use) and you cannot access it by other means. (This is why a dedicated mixer driver for the Scarlett has to be in the kernel, and be exposed via the ALSA-mixer API. A user-space application like scarlett-mixcontrol cannot directly interact with the device on Linux while the soundcard is in use for audio/MIDI I/O.)
So even if you manage to upload some DSP firmware, you’ll still have to expose interaction with it in some way. The ALSA-mixer API may or may not be sufficient.