The second instance, I feel I can comment on, though allow me to leave out details to spare the people involved public embarrassment.
There, the changes, whilst annoying and born out of a complete misunderstanding of a core part of their alleged competency (Imagine a Botanist telling you leaves are always blue because that is the color of the sky), were not going to break anything, just look silly and create unnecessary, but compensated, work.
In that case, I also viewed the specific project finally launching as vitally important to our user base and wanted the results to go public for their benefit, so the decision was made to document and execute on their requests, so we could go live.
Of course, two weeks before our go live date, they changed their requests again ("leaves are not blue, they are violet because of the wave length of light") and had a hard time understanding that changes can have a knock on effect and some things are a bit more complex than Find and Replace. If I had been forced to make those changes at that point, I'd have packed my bags.
Simply said, when my work has the potential to benefit users and I know that arguing, even though I am correct, will lead to massive delays, I'd rather just put that silly request in writing and deal with these things after the users have received what has been worked on. Try to explain when someone is wrong, but if that doesn't work, finish the project, argue later.
Of course, if after the fact responsibility isn't taken, that finished project gets mentioned in my CV for the next employer.