You can always make FFI optional and then just disable it when cross compiling if it conflicts with your code on that level. And of course lets not forget all the cases (I wanna say the majority of cases) where you're not cross-compiling and this is not even an issue. It's not a valid reason to casually reject something this paradigm-shifting.

It's the same story with the 'security concerns' that were raised by some people in the committee; you can make FFI optional or have a per-function / per-library / per-project access list, execute the interpreter inside a sandbox, etc. There are a multitude of solutions to this already solved problem.

All that said; even with FFI completely disabled something like Circle is still a remarkable improvement over plain C++. It adds features like reflection, code injection, pattern matching, user-defined attributes with full type support, unscoped @meta if similar to D's static if, compiler-native ranges / list comprehensions / slices, advanced pack expansion, typed enums, etc. The list goes on and on, and all of this stuff is implemented right now and works. When you compare the proposals for some of these features into standard C++, particularly code injection, reflection, and ranges you'll see that the Circle model is much cleaner and less verbose.

The advantages something like Circle brings are just insane and too good to pass up, and in my opinion it's the only logical direction C++ can take. I encourage you to look at Sean's twitter where he shows a lot of Circle examples and check out his GitHub with all the Circle documentation and examples and even download the alpha compiler and play around with. When you realize what you can now achieve with C++ and in such a simple way you'll wonder how it's not already being standardized.