FWIW I voted for option 2 (compiler macros) because there’s already, in my experience, a “okay now go do some manual work or it won’t build/won’t build in production mode” step in React Native work. Maybe that’s not true for everyone, but for my project which is still encumbered by an early decision to adopt ExpoKit, the need to produce several build variants (QA build lane for TestFlight, white-labeled app version, other reasons), etc., etc. I don’t think that it’s worth making too many structural compromises for developer convenience. Developer life in the React Native universe is going to have some unbuffed burrs and manual checklist-y things regardless of what shadow-cljs does or does not provide.
Why then not vote for Option 1? Simple; I expect that in the fullness of time this macro form might be the entry point for additional goodness that lets us get real source maps all the way out to YellowBox and RedBox, better reloading, and so forth. I don’t mind putting it in my code, I hope to be choosing a platform for the “long haul” (at least another 2-3 years) and so adopting some local dialect is not a huge cost, amortized over that long a period of hopefully-stable development.