I find that baffling: if something is normative (a rule) it can't be wrong, because "wrong" is a concept that applies to claims of fact. It would be wrong to say that you can't carry a soccer ball in your hands, but to say that while playing soccer carrying the ball with your hands is not allowed is neither right nor wrong, just a statement of the rules.
Even if a rule can't be wrong, it can have been chosen based on a flawed assumption, e.g. that Unicode wouldn't change substantially. So the rules in SRFI 14 appear to be normative, i.e. to be rules that the authors intended to be followed, but those same authors might pick entirely different rules now, given how Unicode and Java have changed.
My concern with creating a new SRFI number is that rather than sending the message to implementers "You should update your SRFI 14 tables", it sends a very different message: "You should ditch (or worse yet, keep) SRFI 14 but add this other SRFI to your repertoire." I want people running programs that use SRFI 14 to have them work correctly in the present Unicode environment, not to maintain backward compatibility with what is fundamentally an error.
We have "see also" links between SRFIs for this purpose, and the later SRFI can have a Rationale that explains the relationship between the two.
Perhaps Olin will chime in.