Just tried 054 and for me the Jack and ALSA outputs are working correctly together if on a different device, they don't longer deduplicate too! i'm able to capture ALSA and output Jack and vice versa.
I'm sure that a filtering/checking system can solve the conflicts of ALSA device being occupied when the native jackd tries to hook into it, probably it works correctly for me thanks to PipeWire. i'll try and check these days on a different system where i'll make a native jackd server and report back.
Sample rate will still refuse to go above 48, but now it fails silently rather than try fallback 44,1 and crash.
Everything else works good.
What do you mean by a null input? About the opening, I'm now opening Jack after ALSA and now I at least see all the ALSA ports. It could be that there's a bug in the Linux version that I'm using for testing Ubuntu 16.04, so it's 7 years old - I'm using that version to avoid GLIBC errors between versions).
When Stereo Tool is used as a sink i connect it's inputs to an unused output like _fm (i think it does that by default even when there's no other source). It's apparently fine, but I asked because i'm thinking it might help a potential conflict when testing.
And yeah GLIBC is a pain for proprietary programs, luckily i had no such issue with Stereo Tool (it even works in musl distros like Alpine with the gcompat package), goes to show the great coding sir!
To verify: The issues that you saw, were you at any time using ALSA inputs/outputs? Because if you did, that might explain things.
This got solved in 054, check above. My eastern european English is a bit rough around the corners, my excuses for that