SRFI-68 provides an implementation as its specification.  The
implementation is fully transparent, in that from a port object you can
access the underlying stream, and from a stream you can access the
underlying reader or writer primitive.  This effectively precludes the
use of existing I/O platforms (at least without serious contortions).

The advantages of such an API specified down to the lowest level are
that in general it is easier to come up with a cleaner, more consistent
interface, and have greater flexibility to write portable extensions.
SRFI-6 string ports, for instance, could be implemented more easily and
efficiently in SRFI-68 than the hack of redefining all port operations
as done in the SRFI-6 reference implementation.

The disadvantages are many.  You require implementations you rewrite
their entire I/O subsystem.  For implementations using the host
platform's I/O you add a whole level of complexity they didn't have to
deal with before (mollified slightly by the provision of the reference
implementation).  Embedded systems may grow to an unacceptable size (the
reference implementation alone is over 100k source).  Implementations
without systems-level access will still be forced to to implement the
low-level primitives on top of their platform's high-level facilities,
thus forcing double buffering and drastic performance loss.  In general
you limit people's freedom to experiment with new I/O subsystems.

There is an alternative.  R5RS comes from a tradition of deliberately
underspecifying things to allow different implementations.  Schemes
could be built on a variety of systems and experiment with their own way
of doing things.  Once you agree on the API and the results of
operations, how those operations are performed is irrelevant.

In the area of I/O R5RS is woefully underspecified, lacking even the API
for much needed functionality.  However we can extend this in a manner
compatible with existing implementations without much difficulty.  The
primary problem is the difference between binary and character ports
some implementations have for performance, simplicity and compatibility
reasons.  There are several ways to standardize this interface,
discussion of which is ongoing on the SRFI-56 list.

Other extensions are simply a matter of adding new procedures and
options to handle things such as character encoding, file modes and
permissions, getting and setting the port position, etc.  Most Schemes
already provide these operations, so all that needs to be done is
standardize the interface.

Handling future extensions like SRFI-6 and translation/layer ports isn't
a problem either if you provide virtual/procedural ports as already used
in many implementations.

If it so chose, SRFI-68 could still go the route of portability by dropping
or making optional the bottom two I/O layers.  Full portability would
require a binary/character port distinction, however.

--
Alex