I like paragraphs[-3:-1] in particular; I've had a vague sense of that idea for awhile.
In choosing how to write an app for someone else's machine, you're right, I do start with a list of what's already available to work with. Can I tweak the environment? Use shell scripts? Rely on an interpreter? Use long processes? Windows is particularly limiting, since it's hard (for me) to track down how to talk to the system outside of the standard Visual Studio portal. Everything else (e.g. py2exe) feels a bit hackish or uncertain.
However, for web and Unix applications, you don't use just one language -- your program is the whole system. An FFI is nice, but I'm happy enough to run a few background processes, call a few scripts as needed, in order to do platform-specific tasks, crunch some text, and generally solve the problems that have already been solved. (Maybe this says more about the projects I work on than programming in general.)
For the libraries that we do need -- looking at how I use Python, for instance, I see a core set of libraries that should be in the standard library for any exploratory programming -- everything in C (all operating system features), some way to get at the runtime's internals, string processing, low-level talking to databases, some concurrency support, development tools like profiling and debugging, parsers & serializers for common file formats (XML, JSON, etc.) ... and finally, a way to talk to code in other languages. Re-implement the complete Java or .NET (Mono?) libraries sounds like quite a rabbit-hole, and quite a high barrier to entry for new languages, when the core system libs and an FFI can get you most of the way there with a lot less effort.
