Realizing that a business has more responsibilities than just satisfying the shareholders is incredibly important. I honestly just listed it as an example, there might be better books. I only had brief look at this particular one, since I got the impression that most of it's content is common sense here in Europe...
I'd recommend reading about stakeholder capitalism. E.g. "Stakeholder Capitalism: A Global Economy that Works for Progress, People and Planet" written by the founder of the world economic forum.
A well educated person is a benefit to our society, no matter what one does with an education. The problem is that some countries don't offer education for free which forces some to make such tough decisions.
I for myself have benefited tremendously from my university degree.
Qt would have been my first choice for a long time. Unfortunately the Qt Company has changed their pricing model a few years ago and charges way too much these days. (3950$ per developer and year for desktop and mobile applications. For embedded systems they don't even list public prices...). That said even the open source version is less interesting since one doesn't get official long term security and bug fix updates without continuously migrating to the newest releases.
VmWare Player with USB configured to version 2.0 did the trick for me. I tested it with an iPAD Pro and iOS 14. The VM was running the newest macOS release from a few months ago.
Around here (Austria/Switzerland, Country Side) people only wear smart watches for fitness purposes. Meaning most folks buy Garmin or Suunto devices. Another reason might be that the market share of Apple is lower in general compared to the US/UK.
Personally I love my Garmin Fenix watch. It lasts a week with light usage or up to 18 hours when using GPS. It also offers NFC payment. Notifications might be supported but I honestly don't need yet another device to bother me with messages and such... Meaning I disabled all of them ;).
On another note: Apple might simply be successful because of consistency. They've been iterating and improving on there smartwatch platform for years whiles others change their whole product every few years (samsung) or simply neglect it (google).
As far as I can tell the developer is using Fibers on Windows and boost::context on all other operating systems. You can see that he has a forward declaration in "libgo/context/fcontext.h" and then links against the respective boost assembly files in the CMakeLists.txt.
Having only briefly looked through the code base of libgo. It looks like they use boost::context, which is the only good stackful coroutines implementations I've come across. Not being familiar with your project I'm slightly confused about the statement of "hundreds of thousands of short-lives micro-tasks". This is usually a no-go in case of stackful coroutines, as you would waste too much memory as well as have a lot of overhead.
Regarding your debugging issues. I'd be surprised if this doesn't improve over the next year or two. Clang afaik isn't even fully compatible with the final version of coroutines yet. Microsoft has done a lot of work on the compiler itself. I'd assume that Visual Studio will likely ship improvements once they release VS2022(?). Of course these are only guesses from my side.
Summing it up it sounds to me like you suffered from the curse of being an early adopter. It would be interesting to see if you'd have less issues once tooling and compiler support has improved enough.
Why not benefit from Lewis's work on cppcoro? He obviously has thought through the most important issues one would otherwise also stumble across. Unfortunately cppcoro doesn't look like it is actively maintained, which his why I was looking for other implementations. I'm excited to see how your library will progress in the future!
There are a lot more possibilities. The reason why they are so complicated is simply to give the library developers all possible options. This features is afaik something targeted at them, so that boost, asio and others can implement powerful solutions without language restrictions.
The only way to enqueue a coroutine is to call schedule() within a co_await statement/expression. In this process the coroutine is suspended. Therefore there should not be any coroutine within the queue, which we cannot immediately resume.
I'm afraid I don't have any numbers available to compare coroutines with other approaches. But nevertheless in my opinion coroutines are benefitial because they keep their state (the stack frame, local variables) alive. If you use callbacks you would have to handle all these things yourself. Think about a generator for a sequence of numbers. You would have to store at least the counter variable manually. With a coroutine this happens automatically.