most companies don't even bother calling or writing you to tell you 'no'. or they string you along endlessly until you get tired of asking, or you feel like you're becoming a pain.

Then you should have concentrated on theoretical physics instead of experimental?

And there is a third which was offline at the time, and 2 more being worked on. This is no the last experiment.

No. Spooky Action at a Distance.

the G-V is certified for ETOPS -- extended twin-engine overwater operations. Second, there's no "gliding" involved. ETOPS flight plans are designed for single engine operation. That floating seat cushion is for when both engines fail.

the jet in question is a Gulfstream G-V. Its a very fancy passenger, long-range passenger jet

Even in Class C in UK airspace, you need a clearance.

why downgrade from an asychronous API to a synchronous one?

The problem is that the underlying vendor "operating system" forces you to use events and callbacks for everything. Disregarding sockets for the moment, we currently can't even run a basic Python script that loops flashing an LED and pausing for 10 seconds. That's because the vendor OS expects you to return very quickly from any user code.

So, the first thing we need to do is make the entire system compatible with the Python execution model, ie no callbacks. As part of this it just so happens that sockets become synchronous as well.

Once this is done we have a solid (and conventional, not forced upon us by the vendor) foundation to work from. Then we can build the Python way of doing async IO if needed using the asyncio framework (and perhaps the new async/await keywords).

We upgrade from proprietary "callback mess" API to a de-facto standard socket API. There will be non-blocking sockets support, and thus portable way for async socket programming. I'd love to say that we'll support Python asyncio, but that's pretty high-level framework, and thus have somewhat higher memory requirements than I'd like. We keep optimizing it, but some simpler custom async scheduler may be due.

And for people who want to solve C1M/100/100 problem ("Serve one million clients on a 100MHz device with 100KB of RAM", pun at https://en.wikipedia.org/wiki/C10k_problem), up to going to callback-based API, we may offer that later, but it will be at least based on open and more or less known lwIP API, not on a proprietary vendor shim.

You need a lot more expertise to use an asynchronous programming model. It is much simpler to just busy loop with timed waits. If micropython is going to be easily accessible it needs to support the old school BSD socket API. Beginners and non professional developers want to be able to cut and from other peoples network code and have it work.

100% it is a downgrade. Every experienced developer knows the async model is more performant, at the cost of complexity. My micropython fork is super quick and super stable, it's just not easy to use for beginners. For the ESP micropython port to succeed they need to create groundswell of people using the more compatible APIs. Until now, with the cost of the board subsidising the development there has not been much motivation to even put even posted bug fixes into the port. Using the kickstarter and maybe more community support will maybe bring the ESP port up to a first class citizen.

Personally, my port is a hell of a lot of fun to work with and async is a total win on this board.

This model is certainly more modern and works way better than a for loop

def hello(): print("hello")

esp.os_timer(callback=hello, period=1000)

But, it's not compatible.

YMMV, but for the things I use these boards for, async is overkill--I use these as "peripheral controllers": some sensors, some GPIO, and reporting. Overkill for almost all of that, even with sync-only.