Well - requiring basic frameworks to be re-written for your vanity-OS is the fastest path to irrelevance. Most libraries and frameworks (from curl to zlib/git) assume a POSIX interface. If Fuchsia doesn't care about these fundamental utilities being functional, then that's a flawed assumption regarding the developer ecosystem
Most people aren't running curl on the command line of their phone, and developers use java apis to make http calls. The convention is that the os, i.e. the company, provide the basic frameworks, which is exactly how iOS and android work. The POSIX ship has sailed, you write portable C or in a managed runtime, people rarely write to POSIX.
This adds a build file for the build system they use, and a couple of the config files that would normally be generated by the configure script but presumably the configure script doesn't support Fuchsia, along with an auto-generated source file containing the help output.
So it looks like they have had to make zero actual source changes to cURL; the POSIX compatibility layer and setting the appropriate defines in cURL's config files are sufficient.
The core of zlib shouldn't have any POSIX dependence; it just takes buffers of bytes and produces buffers of bytes.
It has some convenience functions for decoding files given a path or FD, but I'm sure Fuscia's limited POSIX compatibility layer will support that, basic file access is relatively easy to provide in a POSIX library wrapping Fuscia's file handling.
Likewise, I'd be willing to bet that curl and Git would mostly work on top of the limited POSIX compatibility layer; they might need a few tweaks, but likely not much more than the tweaks needed in porting to the various BSDs and OS X, and likely a lot less than is needed to provide them natively on Windows.
Assuming Google is even targeting the developer ecosystem here. I'd assume that most of the users of Fuchsia will be end users, so that's what Google is targeting.
How much of the Android app ecosystem has a strong dependence on POSIX compatibility? I mean, yes, it is Linux under the hood, though it's not glibc, but most software is written against the SDK which abstracts over all of that.
Not being POSIX doesn't mean it's going to be entirely foreign or that it will have no compatibility with software that is already written for POSIX-like platforms. It just means that the basic process management, IPC mechanisms, permissions handling, and so on uses a model which is akin to a cleaned-up subset of POSIX; everything is done via handles, which are a lot like file descriptors but work in a somewhat more uniform way, there is cleaned up management of resource allocations to jobs, memory mapping of processes, and thread management, and so on.
It's not terribly hard to build a POSIX-like layer on top of this; said layer isn't necessarily going to support some of the real warts of POSIX, like the really broken way signals work in POSIX, so some software that intimately depends on this may have to be factored out to support the way that Fuscia handles signals, but for most software this will be a big improvement. Software on POSIX systems nowadays has to jump through hoops to make signals play well with event loops, frequently allocating a pipe that gets written to in a signal handler, so the event loop can pick up that notification later, while in Fuscia that's how signals already work, it's just a state change on a handle that can be waited for in Fuscia's equivalent of select/poll. So in cases like this, Fuscia will add a new code path that is simpler and more maintainable than the one on POSIX-like systems.
