Hopefully I don't annoy anybody since I can't answer directly to your questions. But I have worked with/on IIfxes in the early 1990s.
I always prefer original sources, which means Apple in this case. Apple's Memory Guide:
states (p. 12)
The original Apple leaflet for the IIfx ( http://tech-insider.org/mac/research/acrobat/9003.pdf ) mentions that 80ns SIMMs are needed. In the 1990s I often found that the original memory speeds became difficult to obtain, but faster modules mostly proved to be backward compatible. So this may indicate that your modules, it they prove to be 70ns, may work. What concerns me is that they are copyrighted 1990, quite early, so not sure about the 70ns.
However there are no warnings that LaserWriter memory may destroy fx hardware, so it may be worth a try, given the modules look in good shape. But you may encounter the startup crash sound (a minor down chord) and a sad Mac, which does not mean your hardware is toast but the Mac cannot start. However there is always a risk with unknown hardware. So I do not want to make actual recomendations.
Remember using always 4 identical modules per bank, and start filling up the fx with the largest modules in bank A (the latter required on many Mac IIs but not specifically mentioned for the fx). Parity memory may also be a concern, but only some specific (rare) models are requiring it, other models may (or may not) just ignore the additional information (same module form factor).
Kind of you to think of me, but unfortunately I'm nowhere near competent enough at the kind of low-level programming this would require. Aside from some dilettante dabbling, I'm most comfortable firmly in application space
That said, definitely sign me up for a Linux version (modulo financial disaster). I'd love to have a go at getting the "split world" stuff going (someone hacked rootless mode into Basilisk a while back, I was wondering if using the same approach but in reverse might work to allow handing over parts of the Mac desktop to the Linux side to draw...)
A quick update on this: I've spent quite a lot of time trying to get what I think is the release GEMDOS 1.1 running on this using the DR compiler suite. Unfortunately it is very crashy, and adding debug output seems to move the crashes around, which is not entirely helpful. Part of this is about uninitialised memory, but it's quite hard to debug. I'm considering whether to try to build this using the GCC Atari cross-compiler suite thing for MiNT, which can produce basic TOS executables. Nothing else is required for building the GEMDOS as far as I can see, but it would mean that this wouldn't be able to be self-hosting any more, which would be a shame.