Quote

If there's no response the next few weeks, I will send an e-mail to the Google Group mailing list about our use-case.

I guess you can send it now. Messages in the mailing list are published with a delay, because they are reviewed, and accepted by humans. Which means, that even if you send it now, then don't be surprised, if it will be published tomorrow, or three days later. It is normal. Some people are surprised, and think, that "hey, they censored my message", but very often it is not the case, and the message is later published.

Quote

However, as you know, it's currently impossible to sign a message with a multi-sig wallet.

It is possible, but tedious. If you can sign some message with a single key, then you can do it with multiple keys, just by providing N signatures. Unless you deploy N-of-N multisig, wrapped in Taproot address, then a single signature is sufficient.

Quote

I'm unsure why BIP322 hasn't been pushed or addressed in the past few months/years, but I want to highlight its necessity.

The reason is quite simple: writing code is hard. It requires time and knowledge. And if you have an Open Source world, then people spend their free time, usually without any reward, and they implement things, as they see fit. So, if that was not yet urgently needed by anyone, or if those who needed it, used simple workarounds like "just produce N classical Bitcoin Messages for each public key separately", then just nobody was determined enough, to finish it.

Also note, that there are some workarounds, which are close to BIP-322, but have just slightly different format. For example: you can run regtest, mine 101 blocks, move the coinbase reward from the first block into the output with the same script (this is your "to_spend" transaction), and then spend it (this is your "to_sign" transaction). Then, you share those two transactions, and if your recipient will have the same regtest setup, with the same 101 initial blocks, it can simply send raw transactions, mine a new block, and see, if it is valid or not.