Mark,
Hmm, well, I have thought of one way to implement this. If the main underlying write/print function took an extra-keyword option that said which syntax to print bytevectors/u8vectors in (would be best to use symbols 'r6rs and 'r7rs so as to not program ourselves into a corner with regards to future changes to Scheme) with the display and write functions in the R6RS and R7RS modules using setting the option to 'r6rs and 'r7rs respectively. Only tricky thing here is to decide the default in the base (guile) module. If bytevectors and u8vectors are unified, some level of backwards compatability will be broken with 2.2 and 2.0 since either u8vectors would get printed as #vu8 or bytevectors will get printed as #u8. If the types are not unified, backwards compatability is maintained but then using R7RS and SRFI-4 simultaneously becomes difficult unless we move the R7RS modules entirely over to using SRFI-4 u8vectors. Moving R7RS over to SRFI-4 u8vectors entirely them means we have two different kinds of bytevectors, R6RS and R7RS kinds, and the procedures from each set would have to only produce their respective kind and in some way handle when given the other kind of bytevector (ones that set them probably shouldn't change the type but for ones that return copies, it is hard to say which option is best).
It seems like none of these options are good.
Unifying the types and just having the display/write procedures be different poses some backwards compatibility issues and that when mixing SRFI-4 and R6RS together, things will get messy.
Making R7RS use SRFI-4 u8vectors as its bytevectors means that a lot more work needs to be done with R7RS's bytevector related functions to make them produce the right type and figure out how to handle cases when R6RS and R7RS bytevectors get mixed together as well as deal with making sure that these R7RS bytevectors behave reasonably with existing bytevector related functions (a lot of this has already been done with u8vectors since SRFI-4 has been in Guile quite a while).
I think that both of these options are better than my original proposal, which was reader and print options.