nothing odd..just history
First there was nothing odd about how MacOS Classic allocated memory. The Memory Manager API was written for a 128K Mac which had no hardware VM support. (Well it could be done, but awkward.Thats what the '20 fixed) . Multfinder added the first control over memory size request from applications on launch. A good backward compatible compromise.
You only had to patch out the Memory Manager traps for it to work fairly well with the MMU. And Launch and a few other traps to get it to ignore the SIZE resources. Plus some housekeeping patching. If you knew the ROM inside out, like some of us did at the time, and could recite the Inside Mac Telephone Book from memory, not really a problem. Although in order to deal with badly behaved applications, INIT's and drivers clean enough for a consumer product it was best to write your own pager and Memory Manager. Which is what I did for a product proof of concept in 1995. The client did not like the real world budget numbers for getting to market so never went forward.
I wont go into the whole preemptive multitasking crap. Last time I tried I was lectured by people who never shipped a product for the platform how it "worked". After Mac II 68020/68851 shipped you could easily write preemptive multitasking application. If you only used the low-level API and some fancy footwork in 68K asm. If you used any of the high level WaitNextEvent() etc or any other application running on the box at the time used WaitNextEvent() etc you were going to get blocked. Unless you used the VBL Task / device driver tricks we had been using since 1984. This involved patching some traps to enable you to force switch but if could be done. Max block = 1/60 sec. But got messy with the badly behaved apps. So yeah, I wrote fully preemptive applications on a Mac II in 1987. But it was on a bare box. Just to see if it was doable. For a compiler / IDE.
As for SoftRAM. The senior management people were shady as hell. Which is why they got the big fine from the FTC. The tech people were genuine but out of their depth. The software did not work as advertised because of a genuine bug which the tech guy responsible did not have the technical expertise to either recognize or fix. They had just modified some public device driver code. I always found Russinovich a bit of a blowhard. WinInternals was sometimes useful but after reading the relevant Win16 OS source code later this confirmed he was just a tech anorak and little more. His conclusions in the SoftRAM case did not match the evidence. To him it was some kind of deliberate criminal conspiracy. To me it was just a typical tech balls up with upper management being borderline crooks. A pretty typical situation in fact. In my experience. If the tech guy involved had been a little better the bug would have been fixed (and a few others) and the product would have worked as well (or not) as the other products just like it on the market at the time.To me they were basically plaecbo-ware that just caused weird crashed in my products. Just like "anti-virus" software in fact.
Disclaimer. I was brought in at a late stage to rescue a Mac version of SoftRAM due to my tech background. After one meeting in person with all the people involved (got a nice lunch at the Sony Lot Commissary next door out of it) decided it was just another clusterf*ck so doubled the price of my previous product proposal for another client so they would balk. Which they did, and I bailed as fast as I could. Acquiring yet another tech industry anecdote in the process.
In case you are wondering I would put about 70% pre 2000, and 90% post 2000 dot com companies I have talked to in the same category as the SoftRAM people. Borderline or actual fraudsters. And the real irony here is that Russinovich ended up working for the biggest and most blatant fraudsters of them all. Just as the guys at the Seattle Computer Products to name but one of many hundreds..
Its a funny old business.