Speaking with my editor's hat on, this is something that should have to have a real implementation rather than be speculative. Seeing how the different systems interact in practice would be important. Would you be willing to do that work?
I think we can have either or both of these:
1) A backwards incompatible change to Scheme's syntax by which certain symbols are no longer treated as identifiers but as self-quoting datums. If we do that, we might as well allow both :foo and foo: with exactly the same meaning. (This is a modest extension of SRFI 88, and is currently provided by Bigloo and STklos. Gauche and Gambit support one lexical syntax but not the other.)
2) Adding a wholly new syntax for self-quoting datums that does not overlap with the syntax for identifiers, in which case #:foo is the natural syntax. (This is currently provided by Kawa, Chicken, and Guile.)
If we allow both, then all of #:foo, foo:, and :foo would be different external representations of the same object. No Scheme that I know of currently allows all three.
Alternatively:
3) We could make #:foo not an expression at all, but part of the syntax of procedure calls. In that case, #:foo would be a datum but not an expression, whereas '#:foo would be both. This approach is unique to Racket.
All this is quite independent of how keywords would actually be used in procedure definitions, which could be managed in a variety of ways.
Speaking with my editor's hat off, I don't like the idea of the inevitable complexity that would result.
I'd rather see implementors discuss their experiences with different approaches to keywords, then pick one and implement it uniformly rather than try to implement compatibility with them all. Any particular implementation could be backward-compatible with its old version of keywords, but implementations in general would move toward a single standard. Of course, it may be hard to get any particular implementer to agree to do this, especially once he or she has already implemented another approach.
I think that adding additional lexical syntax to systems that already support option 1 or option 2 keywords would be easy and the result would not be very complex. Getting Schemes that don't support either 1 or 2 to accept either or both would be hard, as it involves completely new lexical syntax as well as a new primitive type. Adding 3 would be the most difficult of all, although it would permit the maximum efficiency in calling procedures that accept keywords.