I am currently writing the I/O procedures for my pet interpreter,
Scheme 9 from Empty Space (plug: http://t3x.org/bits/s9fes/).

While writing the procedures I wondered how to deal with

(close-input-port (current-input-port))

at the top level. While this expression may be useful in
some program code, it is obviously a silly thing to do in
an interactive environment.

I thought I should handle the standard I/O ports in a special
way and signal an error instead of really closing the port.
(This is what S9fES currently does.)

BTW, MzScheme and Scheme48 start complaining about the closed
port ad infinitum and Chez simply seems to ignore the request,
so there does not seem to be an abvious way to handle this
situation.

What do you think?

Larceny really closes the port.  When a subsequent
attempt to read from (current-input-port) raises
an exception, some part of the system (possibly
the exception handler, possibly the repl) notices
that the (current-input-port) is closed, opens a
new standard input port, and makes it the current
input port.

You might want to look at one of the R6RS formal
comments filed by John Cowan: "The standard-*-port
procedures should return a fresh binary port."
This will be formal comment #183 when the R6RS
editors publish their response (due in mid-April).