As the name suggests, this wraps the whatever build system that the dependency is using rather than replacing it with Meson. Say if you depend on Boost and Qt, you will end up using both Boost Build and CMake in addition to Meson (most likely there will be a couple of more build systems if you are also building Boost's and Qt's own dependencies such as ICU). This has two major drawbacks:

1. The build in step-by-step rather than end-to-end. Meaning that you first build Boost completely, then Qt, and then your application. With an end-to-end build you would build everything with a single build system invocation with the build system "seeing" the entire build graph. In particular, this would allow you to build only what's necessary and faster.

2. If something goes wrong in one of these dependencies, you better be prepare to become an expert in whatever build system it uses.

If you want a true Cargo-like experience in C++, a better option would be build2, which replaces rather than wrapps the build system (and, yes, it has Boost and Qt packages): https://build2.org

For more details on what an end-to-end build can give you, see: https://build2.org/faq.xhtml#why-package-managers