A near-empty default.haxproj file was created during project creation, as were a pre-authored tmpl/default.haxtmpl.html file and a default-build directory. Here's why they all share default in their names and how "setup names" can be leveraged for more finegrained project experiments / variations.
When HaXtatic is run, it is at a minimum always given a project directory path to work in, but following that one required command-line argument there may be any number of *.haxproj file names (not paths, and separated via white-space). Only when these aren't specified does HaXtatic actually assume a single default.haxproj is to be used.
So all the specified *.haxproj files are loaded in sequence and combined-into-one in memory on the fly. This may result in later definitions overriding previous ones, which in turn can be really quite handy (once the need materializes).
If any one of these named files doesn't exist, it is quietly ignored. If none of them exist, the above-mentioned fallback to default.haxproj applies. If that one doesn't exist, a minimalist pre-authored version is re-created to demonstrate just how seriously HaXtatic takes all this.
The above logic then easily gives rise to the concept of "named setups", that is: multiple separate (differently named) sets of <name>.haxproj + tmpl/<name>.haxtmpl.html + <name>-build/ co-residing in parallel within the project directory.
This may sound somewhat convoluted, but consider that (despite this functionality emerging rather on a whim upon determining the real need for and utility of supporting multiple *.haxproj) there could certainly well exist use-cases where developing/generating a number of "quite-similar-but-differing-in-various-minor-or-major-details" versions/variations of a project —from partially shared, partially differing contents, templates, snippets, settings— is upon reflection ultimately called for. Happens to the best of them!
Since most other variations can be finely controlled entirely via the *.haxproj files, the "named setup" concept only affects these 3 entities of <name>.haxproj + tmpl/<name>.haxtmpl.html + <name>-build/ .
The very first of all the specified *.haxproj file names supplied over the command-line, as per above — but existing or not, loaded or not: the first one names this setup! All this shows how new projects end up with the standard set of default.haxproj + tmpl/default.haxtmpl.html + default-build/ — the setup name falls back to default absent any explicitly specified other *.haxproj file names.