This most recent (as of this blog post) macOS update (and new architecture) has raised a number of issues with REAPER development -- I'm documenting them here in hopes of it being useful to someone:

• If you're using the Hardened Runtime (for notarization) and have the com.apple.security.device.audio-input entitlement set, if you link against the latest SDKs you also _MUST_ have the NSMicrophoneUsageDescription set in your application's .plist, otherwise it will never prompt.
  
  
• If you create a CGImage using CGImageCreate(), draw it using CGContextDrawImage(), and release it, that underlying image data is accessed by the system at a later time when the drawing actually occurs. This will cause all kinds of bugs in all kinds of software. We work around it by forcing Metal on various views where this isn't safe.
  
  
• If you call MIDISend() with 250 or more events at the same timestamp, it will crash. (thanks to @helgoboss for isolating this)
  
  
• Rosetta2 is amazing -- just don't try to get it to run x87 code. EEL2 still generates x87 code, so JSFX on REAPER-intel on an M1 is incredibly slow. A quick benchmark in EEL2 gave me this: arm64 native: 1.25s, arm64 bytecode: 4.18s, rosetta2 x86_64 bytecode 9.18s, rosetta2 x86_64 x87 code 59s. (bytecode is EEL2 in portable non-JIT mode). The benchmark I used was actually pretty low on math, I think on DSP code it's probably even worse, like a 100x slowdown.
  
  side note: so now, I'm trying to figure out the best way to deal with this. I did an EEL2-SSE branch a while back, and I have it working again, but it's about 20% slower than the x87 version in a lot of important cases. Tempted to make a jsfx-sse.dylib and only use it if running in Rosetta2. Also tempted to overhaul EEL2 to optimize for non-stack based architectures (which would also greatly improve the aarch64 version). The answer probably is something more incremental, like introduce some helpful optimizations into EEL2's code generation that will help get the SSE version up to parity. Of course, there will be little quirks that differ between the SSE and x87 versions, so those will need ages and ages of testing to get ironed out.

There were other things that came up that aren't as interesting. When launching Audio MIDI Setup.app, the new path is /System/Applications/Utilities/Audio MIDI Setup.app rather than /Applications, for example. Apple likes to change the appearance of NSTableViews and then provide ways to get them partially back to their previous style, but not all the way. Stuff like that... Dealing with macOS updates and compatibility is really not enjoyable. So tiring. Though the x87 vs SSE thing isn't their fault -- no x86_64 system has ever not had SSE...