A big challenge in unifying tools like mix and rebar3 is that they take a different approach to extensibility and configuration. Mix essentially lets you extend it by writing arbitrary tasks in arbitrary Elixir code that you evaluate within the tool.
Rebar3 aimed to have a declarative configuration format above everything and tries to actively restrict what you can do in its config files (there’s an escape hatch with rebar.config.script), and we aimed to make things extensible through the plugin system.
Mix supports semver and will, as far as I can tell, unify the dependencies and extension versions it needs. Rebar3 started in a world where a single lib would often have diverging git tags, app files, and documented versions; as such the dependency handling algorithm is based off a “distance from root” comparison (the version closest to the project root wins, with the assumption that more of its functionality is exercised). When it comes to plugins – and plugins include ways to load custom compilers and dependency fetchers – we instead handle sequences of loading and unloading dependency sets dynamically between libraries required for plugins and deps, so that they don’t clash.
That’s without mentioning the distinctions in profiles, configuration handling, releases, and so on. I think at this point the philosophies of both tools diverge enough that it would be extremely hard to unify them without breaking major parts of either ecosystem. It’s already a bit odd when it comes to dep resolving (we don’t have optional deps in rebar3!)
My prediction is that if we were to do it, we’d have to pick an intersection of features, and the rest would be best effort. So any lib from either ecosystem that uses a more advanced feature set from their build tool would be at risk of breaking.
I’m betting more on our ability to keep interoperating between mix deps and rebar3 deps as the way forward, since the bridge appears easier to gap here.