Yes, building with Hugs is currently the preferred way because it does not depend on any pre-generated code.
The stage 1 build uses a pre-existing mhs (usually runhugs wrapped mhs) with make.
The stage 2 build uses the stage 1 mhs with mcabal.

It's not immediately obvious to me how exactly mhseval.js is generated, but is there any reason you can't generate it using the stage 1 or stage 2 compiler?

I was trying to get it to work via

mhseval = pkgs.haskell.compiler.microhs.overrideAttrs (prevAttrs: {
  microhs-stage1 = prevAttrs.passthru.microhs-stage1.overrideAttrs {
    nativeBuildInputs = [ pkgs.breakpointHook ];
    postBuild = ''
      make bin/mhseval
    '';
    postInstall = ''
      cp bin/mhseval $out/bin/mhseval
    '';
  };
});

and didn't manage to get a useful output that way, I did try to copy it from stage1 to stage2 later, but I've changed a bunch of code around this

I'm starting out with nix and having trouble with system library fiddling. GHC cannot load the shared object for z3, though the C headers are found just fine.
This is my flake definition:

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs { inherit system; };
	in {
		devShells.default = with pkgs; mkShell
		{
			packages =
				[ haskell.compiler.ghc914
				  z3
				  stack
				  libllvm
				  libclang
				];
		};
	}
	);
}