My experience with working on a project that's converted to Meson is that its main flaw is its philosophical commitment to inflexibility. You do things the Meson way or not at all. Want to have file foo/bar/baz.c compile to foo/bar/baz.o in the build tree? Nope, must be foo_bar_baz.c.o. Want to have source files with a .inc.c extension which aren't compiled like plain .c files? Nope, you need to rename them to .c.inc. Want to write a wrapper function around a Meson builtin like 'dependency' that adds extra functionality to it? Nope, Meson doesn't provide functions in its build scripting language. Want to have a build rule be "run this perl one-liner"? Tough, Meson will mangle it by turning all the backslashes into forward slashes so you need to put it into an external script file. And on and on. And we needed to upstream new functionality into Meson before we could even convert to it in the first place!
My view of build tools is that they must provide flexibility and escape hatches, because on a sufficiently complicated project eventually you're going to need it. The Meson designers have a strongly opposed philosophy. If you agree with them on that design philosophy you'll probably be happy using Meson, but if not then you're likely to get frustrated with it every time you do anything non-trivial with it, I think.
So I have zero experience with Meson but quite a bit of experience maintaining C++ codebases of varying quality and with all sorts of build systems (qmake, autotools, cmake, simple Makefiles, ...) and honestly I think if you want to make a build system that works reliably, doesn't take 3 months to learn to use correctly and gives you all the features you want you'll have to cut on flexibility.
Otherwise you end up with a complicated mess that everybody uses differently and you have to relearn on every single codebase.
Rust's cargo is one of the most inflexible build systems I've ever used. It's great. When I open any random Rust crate I know exactly what to expect, where to find what I'm looking for and what I need to tweak to fit my needs.
>ant to have file foo/bar/baz.c compile to foo/bar/baz.o in the build tree? Nope, must be foo_bar_baz.c.o. Want to have source files with a .inc.c extension which aren't compiled like plain .c files? Nope, you need to rename them to .c.inc.
Great. Sold.
Not that I particularly care about these particular stylistic choices, what matters is that I know that any project using Meson will work the same way. I never liked the "mod.rs" convention of Rust, but I definitely think that it would be worse if you could override it on a per-project basis.
Again, I have no first hand experience with Meson so maybe it does suck but in my book being opinionated is actually a very good sign and I'll definitely have a look at it if, god forbid, I have to start a new C++ project in the future.
Rust's cargo very much has a first mover advantage. Since (almost) all rust projects use cargo, it doesn't have to fit/work with any other styles. I think this position is close to untenable in the C++ ecosystem and for existing codebases therein, since it's too much effort to port large dependencies and thus, it remains very hard to convince people to adopt it. But I'd love seeing something like this, since cargo is pretty much the best thing ever in this space IMHO.
The only way I can imagine this working is a very large vendor pushing it hard for their platform. This is effectively just Microsoft, all other platforms either use Java/C#/Swift/JS/... or are much more community driven.
There's many problems with meson and cmake, but as for meson. Meson is the kind of build system that makes using tools hard as it forces certain workflow to you. It detects the compiler and tries to be too clever what you can do with it and what you can't. For example recent mishap was that it detected emscripten compiler and didn't allow me to use it as non cross-compiler and so on. There's no way to build static libs, if the project hardcodes shared library building. The codebase is also pretty nuts, I welcome you to go read it.
(GNU) Makefiles with some standard variables and pkg-config are still the king. Cmake and meson can work okay for very simple projects, but other than that I'd recommend always using native build system for each platform, or going Makefile + mingw route (if you need windows builds).
Using native build system eventually saves you time and headache, especially when these "portable build file generators" don't support some feature you absolutely need, or doesn't allow you to put that command line flag in one of the tools that gets executed under the hood.
CMake also absolutely sucks at finding system dependencies when everyone uses those "FindFooBar.cmake" files with hardcoded search paths and what not, instead of using pkg-config. This forces many packagers to hack the projects build system, because the project would otherwise link to wrong library, or not find the library at all. With pkg-config the distributions can provide the correct paths and flags when linking against something.
Autotools, while slow and generates tons of shell script that's compatible with all sort of ancient shells and platforms, still manages to offer a standard interface to packagers and fine tune exactly how things get linked, how things get configured and where stuff gets installed. Autotools in general is less headache to packagers than meson or cmake.
I think being sort of "rigid" is part of the appeal of Meson and definitely intentional (keeps complexity down). I can understand how that might be off-putting or even obstructive to some though. But being too flexible is in a way what made CMake and autotools so bad.
I have only done really small stuff with Meson, so I haven't had problems like the Emscripten one you described and I can't say much about it.
Regarding static libs Meson docs explicitly state that "library" is preferred over "shared_library", so that you can choose at build configuration time. If some dependency of yours does not follow this advice without having a good reason for it the fault is with them.
I use CMake over Makefiles, because for libraries you want people to be able to easily integrate your stuff, so you need to use what everyone uses. And in general it's still the best way to have a (mostly) platform-independent build. Yes, almost all non-trivial CMake files have a bunch of platform-specific extra stuff, but at least you can do it. I also cannot believe how bad the dependency finding works. It actually doesn't work more than it does work. Very often even with libraries that I installed through my systems package manager. I also consider CMake horribly flawed, but it's still better than raw Makefiles.
I'm not sure I agree with the complexity. You can go read CMake's and Meson's source code and probably agree with me it's not very trivial. Sure they can provide you a "cross-platform" build with ease, but it doesn't come free. You are giving away flexibility and it only works when it works. When it doesn't work you usually have to employ ugly hacks or your build files start to creep in way more complexity than would be needed with native solution, or even by using a simple Makefile or heck even a shell script. In worst case, you'll become a CMake or Meson developer to add that missing functionality, or fix bugs whatever, just to get your thing to build.
I also want to point out that the build system isn't just for you, it's also for the users and packagers. Especially for packagers it's important the flexibility is there.
I used to use CMake myself a lot way back as well, but eventually got fed up with its problems it always caused (mostly when other people tried to package my projects and there was always some incompatibility or dependencies not being linked correctly, etc...).
I also used to think Makefiles are bad, but actually when I sat down reading the GNU Make's manual many things clicked with me, and (GNU) Makefiles are actually very good at building stuff and they aren't that complex at all. Sure there's lots of bad Makefiles around the internet (just like there's also bad CMakeLists) the Makefiles are very powerful when written correctly, and most importantly they are very very fast.
MinGW still has downsides, like using the ancient version of the C runtime, with missing features and bugs. There are also ABI issues between MinGW and VC++ - more so if you're doing C++, but even in C, stuff like FILE* or locales is not interoperable.
ABI issues are fundamental problem with C++, not really mingw's fault. If you have to use binary library in C++, then you have to use the same compiler it was compiled with and with the same compiler settings.
ABI issues are a fundamental problem with having many different ABIs - things are much better on Linux, where there's a clear standard, and everybody conforms to it. VC is the de facto ABI standard on Win32, but I'm not even sure to what extent it's documented, beyond the bits that are needed for COM.
In any case, I'm not trying to blame anyone here - just pointing out that MinGW is a second-class citizen when it comes to C/C++ development on Windows, and this is usually more important than having access to MSYS2.
