- they want to be able to switch to newer APIs when the underlying OS adds them (though in Edge's case it's more likely it was written from the ground up using newer APIs)

- they quite possibly want to use "you can get the new browser only if you upgrade" as a carrot for OS upgrades (they explicitly did with IE, I haven't seen anything explicit for Edge but it wouldn't surprise me if they're still taking that approach)

I do hope you find a service that fits your need, but this is very likely not intending to be it.

(Basically it should run on anything more complex than a static site host. Though it's also true that sqlite would probably be a cleaner choice for the datastore without losing any of that benefit.)

Firefox Sync only syncs with versions of Firefox, and Chrome's sync only syncs with versions of Chrome, so they'd have to switch mobile browsers too just because they switched desktop browser (and unlike on desktop, I've found Firefox for Android to generally be clunkier to use than Chrome for Android).

And that second link is about Chromecasting from Firefox for Android, not the desktop browser. Being able to send stuff from desktop Chrome is definitely a convenience someone could get accustomed to.

Some rely on the device itself to enforce it, but that's obviously fragile if you can bring your own device.

Some check the TTL of your packets when they enter the carrier's network, because tethering is at least one more hop and so even if your computer's OS and phone's OS agree on what TTL starts at, the TTL will still be different than expected for your device's platform. Obviously this can still be mitigated by adjusting your TTL, but outside of software that'll handle this for them, that's already beyond a lot of customers.

Some even take the route of only checking HTTP traffic, and detecting tethering based on User-Agent, but I think a lot have abandoned that because it doesn't catch other protocols, and is easily bypassed even on HTTP.

A certain MMO I play recently had a limited-time event built around figuring out the meaning of different clues (locations to go to for the actual meat of the event), and despite a fairly large number of variations, people had collectively figured out just about every possible clue->location mapping within a matter of hours.

That's not to say you can't prevent cheating, but that even with relatively little incentive (that whole clues thing gave only a single cosmetic item, and anecdotally I've seen very few people actually use theirs) users can and most likely will outpace any attempt to prevent it by means of varying the problem.

Unreal's license for obtaining the source does not permit you to redistribute in source form, so you can't comply with their license and still fulfil that point.

While it's certainly trivial now for most anyone to obtain that source independently, you can't include that source in your own project while still distributing your own project under any license that the OSD would label as open source.

He's very good at taking an idea and making it work, then building new stuff on that, but less so at actually making things robust in an architectural sense. Moving on to the next thing that interests him also doesn't help that.

A lot of the biggest hiccups in Minecraft's stability are more-or-less directly caused by having to work around stuff that was coded in a way that made sense at the time, but gradually fitted less and less well to the game as it now stood.

I'd say at this point a lot of Notch's original code is outright gone, and that's a good thing. His vision is still at the core of it, and that's what he really brought to the project.

1) Easily-distributable "mostly-compiled" bytecode form (JAR files).

2) Wide install base for the VM needed to run said bytecode.

Without #1 you need to recompile for each new platform, even when avoiding platform-specific calls, and without #2 the advantages of #1 can't be used without requiring your users to install other stuff just to run your software.