Using XML Canonicalization as the preprocessor for signature generation and verification has proved less than satisfactory. I think it's worth considering replacing C14N with something designed specifically for this role, with the benefit of hindsight wrt the problems that have been uncovered with the existing architecture.
In order to play the role of guaranteeing the integrity of a document, what must be signed? I think the right way to address this is to look at infoset items and properties. Here's a suggested set of things which must be covered:
Note in particular that no information about namespace bindings is required/involved here -- no prefixes, no namespace attributes, no in-scope namespaces.
The previous section doesn't really answer the question -- we need a byte sequence to digest, not a tree of abstract information items and properties. You could imagine as trivial an answer as "Treat the infoitem/property story as a simple object model, and serialize per e.g. JSON". That might be too easy an answer for some, and in particular it would be horribly inefficient wrt namespace names.
The alternative I think would be worth exploring would be a variant of XMill. This would massively reduce the redundancy, as well as possibly improving the quality of the digest produced.
I think Ed Simon's attitude is correct here -- if fidelity of prefixes in content is an issue, type-aware processing would be required to convert e.g. QNames and XPaths in content into an expanded-name form.
I think a new XML Signature WG should include in its charter exploring the possibility of replacing C14N completely in the signature architecture.