You write this as if XMLDSIG was straightforward, but people who have worked with XMLDSIG before know that it is not, and people who haven't worked with XMLDSIG should know that they need to research new cryptosystems before slapping them together out of spare parts.
Just to clear it up and state it plainly: it is never reasonable to assume that a given XML library is suitable for building XMLDSIG on top of or alongside.
Drop what? encoding/xml was never a reasonable building block for SAML and XMLDSIG, that was pretty immediately apparent from the library itself, and the Go project never told people they should using encoding/xml this way. They never picked it up in the first place, is what I'm saying.
Just to clear it up and state it plainly: it is never reasonable to assume that a given XML library is suitable for building XMLDSIG on top of or alongside.