That's where the "needs to know which machine it's running on" part is important...
Interesting. So did you *just* patch a NOP over the SysErr trap that otherwise would have popped up the "This disk will not work on this Macintosh/model" dialog, or did you do any other patching to the routine that "matches the version number of the ROM is loaded and run to patch the ROM specific bits" to hint that it should try to pick something close-ish, like an LC II?
Bbraun has obviously done some fairly deep hacking of the MacOS, so he's far more qualified than I am to say if there are any theoretical blockers that would make such a patch unworkable on an LC 475s. Off the top of my head two things that it seem *might* cause issues are:
1: The 68040 Macs require that a little chunk of software be present to handle floating point exceptions triggered by trancedental functions present in the 68882 but missing from the onboard FPU. (And I *also* believe there's another wrinkle associated with the LC040s in intercepting floating point operations, but I don't know if that affects MacOS at all.) I imagine said handler is in the ROM, but I have no idea if it actually requires explicit support from the loaded System to work properly.
2. The LC475's devnote says that the version of Quickdraw used on "all 68040 Macs" is enhanced to use a 68040-specific block move instruction. I have *no idea* if said enhanced Quickdraw would cause impossible-to-solve problems with System 6.
By all means it would be interesting to see if you could indeed make it boot *and* determine if it were actually stable/usable on a from-the-factory 68040 machine.