What do we gain from moving to Meson or CMake (what's the rationale here)? GNU Autotools is complex, but powerful and mature (its cross-compilation support Just Works, for example), and it is more portable/bootstrappable than other modern alternatives.
Meson language is simpler. This would allow to attract contributors and packagers. IMHO if you move to Meson and implement proper semantic versioning, you can freely delegate all packaging jobs to distro packagers (which is the right way to distribute an open source program).
Sadly, that's an oversimplification of the challenges of packaging Jami. I wouldn't expect the build system to be the determining factor in having Jami packaged in distributions (and if anything, GNU Autotools is ubiquitous and for this reason usually the best supported in many distribution tooling). The more problematic aspects of packaging Jami for distributions are:
Custom patches to libraries such as pjsip and ffmpeg.
Cutting edge dependencies such as Qt 5.15 that are not yet offered in some distributions.
Dependencies such as qtwebengine (chromium) which are not offered in some distributions due to unclear licensing (?) concerns (GNU FSDG and Chromium).
In Debian stable for example, you don't have a recent enough Qt package. That means a recent Jami Qt client cannot be properly integrated into such distribution as of today. Package management system such as Guix packs, snaps and flatpak can help here, but they come with their own class of challenges (integration with the host).
While it's understood that supporting multiple build tools is a bad idea, having at least one project file with cross-platform IDE integration would be best. CMake has project file generators for most IDEs but also direct integration with QtCreator using server-mode. I think Meson project support should be verified for:
Just for the record, as a distro packager actually packaging Jami I do prefer meson, it’s much more convenient for us (we have a wrapper around meson that sets everything we need) and does not have all the quirks of autotools like overlinking. In particular, reading a meson_options.txt or even a meson.build is nothing like a configure.ac or even generated configure. We have seen a lot of projects moving from autotools to CMake, and now to meson.
Now I understand that your case is not standard as you build multiple projects together, as well as dependencies in your case, which all have their own build system.