[Sebastien Tardivaud] If it is raising the undone state of the items of the sprint, what ever the state of the status process, they all past again in to do/in progress. I check if the dev propose it first and if not, i push the point. To keep trust, we need to stay transparent. And to be sure we don't miss the inspection to adapt or not for each item, we need to be clear its not done. After i push to see with all the scrum team "with this new statement, what can we focus as valuable increment ? And what is the new tactic with the new constraints we have ?"
Minimum, i push to have the addition of the acceptance criteria to resorb the problem in the descrption where its appropriate.

Finslly i remind to everyone, sm include, commited in the sprint backlog. Then, we should consume,as team, the minimum time and effort to subject what is not about it. And discussing process internal of the team or "how can we justify it" its clearly nit valuable at this moment. Be courageous keep the focus and the commit on what deliver the best value.

If we dont success to achieve the sprint goal (or the commited list), we discuss about it at the review "witout blamming, what do we do with the new state of backlog and informations learned ?"
To finish, a retro abou it.

[Doug Rabow] I guess that depends on if your goal is to do scrum as defined in the guide or if it is to deliver working software to a customer. If it's the latter I would suggest that if something is missing from the DoD it should be added as soon as we discover it, and if that impacts the sprint goal so be it.