I'll give some bullet points that might be of interest, I agree that they need a funky infographic or similar.

• it's a build system itself, it doesn't need make or whatever and compilation speeds are similar to ninja

  • which means it can do things like distributed building
  • and implement local caching, like ccache but supporting msvc as well as gcc/clang (actually msvc might be disabled at the moment)
  • .. likewise remote caching, like Mozilla's sscache for teams (again supporting msvc/gcc/clang)

• it has its own package manager but also works with pretty much all other popular package managers

  • the build system will default to any matching installed system libs unless you say otherwise ({ system = false} on a per-included package basis)
  • it downloads and installed necessary packages when first building a project
  • package manager can use pre-compiled Windows artefacts
  • can use the hosted online repo, or our own online or local repos (multiple if we want)
  • location of alternative repos can be set in xmake.lua file or configured on command line (or config file).

• can configure project with a TUI menu xmake f --menu

It just feels more straightforward and logical to me too. I know that's subjective, but the objective part of that is it's a unified build system, cache system and package manager that sets out to work with other tools.

(edited: tidied bullet lists)