So, not a build tool that works across languages, but a generic mechanism for bootstrapping and running a build tool that works across languages. That actually sounds pretty reasonable.
Okay, i, the original developer, somehow obtain Tool X, and tell it to do a number on my project. It works out or is told what build tool i'm using, and generates a portable shell script in the project root. Later, you, the developer who has picked up my random open source project, can run it:
./xmake
Or on Windows:
./xmake.bat
That then uses some almost-definitely-available HTTP client (curl on Linux, some PowerShell access to a .net client on Windows) to obtain the binaries necessary to run the project's build tool, caches them somewhere sensible so it won't need to download them again next time, then sets up whatever environment is needed to run the build tool, and runs it.
For example, if i have a Gradle build, it will download a JDK, unpack it somewhere, export JAVA_HOME, and run ./gradlew build. That will then download Gradle itself and run it, which will download the dependencies and build the project.
If i have a Cargo build, it will download the appropriate version of Rust, then run Cargo.
The top-level script could support a number of standard targets - 'all' (the default), 'assemble' (just compile and link the main code), 'test', 'package' (put everything in a zip file somewhere), etc. In each case, these would translate to the appropriate invocation of the real build tool. Where a build tool doesn't have the concept (does Cargo do packaging in a zip?), the top-level script could provide a shim.
Does that make sense?
If a target language already has tooling to install specific versions of its SDK, then the top-level script should chain to that, instead of duplicating its functionality. That means rustup for Rust, ruby-install for Ruby, and probably SDKMAN! for Java (obscure, but it exists).
Where a language doesn't have such a tool, perhaps it could be shoehorned into an existing one. SDKMAN! is nominally language-agnostic, so perhaps that.
Probably the biggest stumbling block is C/C++. They don't even have a standard build tool, let alone a standard SDK version manager. What tools do exist often assume that they can use system versions of compilers, libraries, etc, rather than ones from a particular installation. Still, i've written enough C++ build scripts to convince myself that this would be possible, even if was a bit painful.