This is what I was expecting (just another lesson in the dangers of writing enormous paths by hand.
This is also right.
I definitely agree that making this work is important to giving a good first impression! I used Homebrew's minimal Racket myself for several Racket release cycles when I was relatively new to Racket.
Adding an explicit raco setup step will definitely avoid the immediate problem, but I think it may be doing so by producing a duplicate set of .zo files.
I'll try to describe more of what seems to be happening from the Racket side, in the hope that someone else can figure out, if this is right, how Homebrew might be getting into this state.
Since the Racket commit I mentioned above (February 2021, included in Racket since 8.1), running Racket's ./configure with --enable-origtree=no and --enable-macprefix, as Homebrew does, installs Racket with source files under ${PREFIX}/share/racket and the corresponding .zo files (which are architecture-specific) under ${PREFIX}/lib/racket/compiled/ (plus path elements for the absolute path to the source file). It then arranges for the result of (find-compiled-file-roots) to be something like the one you got:
'(same #<path:/opt/homebrew/Cellar/minimal-racket/8.5/lib/racket/compiled>)
where 'same means a relative path, e.g. foo/info.rkt compiled to foo/compiled/info_rkt.zo.
Racket will look for compiled files in both locations, but, if the compiled files are missing or outdated, it will write compiled files in the first location.
From the diffs you posted, it looks like raco setup is not using the existing compiled files under lib/racket/compiled, very possibly due to mtimes, and is instead generating additional compiled files in compiled directories relative to the source files.
Adding the ./configure flag --enable-sharezo would have Racket install compiled files relative to the source files, so (find-compiled-file-roots) would just produce '(same). That at least would mean that raco setup would use or update the existing .zo files, rather than generating a second set. The downside is architecture-specific files under share/, for those who care about that sort of thing.
Of course, it would be even better to figure out what's going wrong (very possibly with mtimes) that's making Racket not use the compiled files that already exist.
From the Racket side, I wonder if we should use mtimes only as a shortcut to hashing the source file, as Zuo does.