Point taken, Lou. But we have the build die as soon as the @validUntil is over on purpose, to force our hand at paying attention to getting the deprecated thingy out. So (IMHO), we can't just automatically pop up the deprecation date forward. That said, you're right, even if (as Martin put it elsewhere earlier today) "dev [is] the branch which will break things, while master is the branch that shouldn't break", we shouldn't leave dev broken for too long, lest other errors that don't get checked correctly become introduced. But the good news is I'm working on a fix now ... can't imagine I'll get it done before my next meeting in 12 mins, but (crossing fingers) likely shortly thereafter. (And, BTW, the thing that seems to break Travis's build on this is not the loss of data.*, but the loss of <catchwords> other than a descendant of <msDesc>.)
Er no, I am not misinterpreting the problem. The problem is that the current build is broken, and it's not as if the current brokenness was a complete surprise. You knew this was coming months ago, when you set the deprecation date on the old datatypes. If implementing the deprecation is proving tricky, the answer (in my old fashioned opinion) is not to say "oh well it'll work eventually when Syd gets round to it", but to say "drat, we will have to move the deprecation date forward", sine die if necessary.
I guess the way I'd look at it is that because of the deprecation, the build is already broken. It might be broken differently if you merge your branch into dev, but hopefully it'll be less broken. Even if what you have isn't 100% right, it's still going to be better, and we can work on fixing it completely.