>>> R7RS `write-bytevector` writes the raw bytes to a byte port, so no particular syntax will be used.
>>
>> My mistake! I had read the specification and completely misunderstood that procedure. I will correct that in the next draft. Thank you!

No problem. I don't think there's anyone writing on the SRFI lists who
knows the standards in full. We misunderstand and mis-remember details
all the time.

>> Then we have a precedent against my proposal’s permissive use of this notation by the writer in implementations whose reader supports it.

As Marc says, it's wiser not to `write` any special syntax until there's
an established convention for how to configure `write`. It's easy to add
custom writing later, but harder to preclude it once it's established.

>> And also from SRFI 169 a negative precedent for my question about whether or not an import should be required before using this fancy notation.

If you're referring to the `(import (srfi 123))` form, it doesn't import
lexical syntax (aka read syntax). Once Scheme has started reading a
source file, the lexical syntax in that file can only be changed by #!
directives. We don't have many of those, but here are some known ones:

#!r6rs          ; switch to R6RS standard syntax
#!chezscheme    ; switch to R6RS + Chez Scheme extensions
#!fold-case     ; symbols are case-insensitive in the rest of the file
#!no-fold-case  ; symbols are case-sensitive in the rest of the file

We could add a `#!srfi-207` directive as well as a `#!srfi-169` one, but
those quickly add up to quite a few. It seems a more general mechanism
could be useful.

(import ...) can however import macros defined by `define-syntax`. In
Scheme both macros and lexical syntax are casually called syntax, which
can be confusing.

>> That said, I expect that this SRFI (if it goes all the way to final) will go on the ballot for R7RS-large when notational issues come to be considered. So objections about not being RnRS-compatible arguably go away then.
>
> I don't think so because R7RS(-small) still stays as it is. The upshot
> would be that R7RS-small data written by R7RS-large systems would be
> unreadable by R7RS-small systems. This would go at least against the
> spirit of the charter of WG 2.

Good point. R7RS-small and R7RS-large interoperability is important.
It's also useful if as much R6RS and R7RS syntax as possible can
interoperate.

> A possible way-out would be that SRFI 207 defines a SRFI 39 parameter,
> initially set to #f. When it is paramerized to #t, "write" and friends
> may use SRFI 207 in printing. This is still an incompatible extension
> to "write", but it wouldn't probably hurt much.

Yes, parameter objects would probably be a good way to configure
`write`. Common Lisp uses dynamic variables to control its printer (all
*variables* listed in <http://clhs.lisp.se/Body/c_printe.htm>), and
those are CL's equivalent to Scheme parameters. It works well.

Perhaps we should have one parameter for the `write` state. The
parameter's value could be an object that is extensible for different
purposes (some of which we don't know yet).