1) Allow a running program to retrieve this same information as a Scheme object by calling a procedure, which allows the program to customize itself.
2) Make it clear if stand-alone compiled programs written in Scheme may, must, should, or should not support this SRFI. If so, the compiler will have to effectively synthesize the procedure mentioned in #1 at compile time.
3) Return non-sexp lines as (non-parsable "blah blah blah") rather than just discarding them, as there may be valuable information in them.
4) Add "compile-command" so that systems like Chicken and Gambit with standalone compilers can be accommodated.
5) Since there is no limit on the length of lines (and modern *ix tools impose none), you might as well remove support for multi-line S-expressions. This will encourage people to use the "Hacks for lists" style, which should be called "Simplifying complex lists".
6) Consider removing support for nested lists also for the same reason. (Maybe you meant to, but the Specification part doesn't actually say that.
7) Platform support is kind of a mess. I'd get rid of plain "platform" and add "platform-userland". The number of bits in a platform doesn't really tell you enough because different fundamental types can have different sizes: I'd go with platform-(memory-)model a la the features list: lp64, llp64, ilp32, etc.
8) For the sake of unambiguity, private properties should use / or something besides - to connect the name(space) with the property name: fantastic-scheme/POM.
This is more controversial because it isn't known at compile time: what about adding uname?