https://www.youtube.com/watch?v=B7MIJP90biM
The customers might even be happy with it, because it would mean they wouldn't have to admit their requirements were stupid.
I personally prefer it to be instructed when my requirements are stupid (if there really is strong evidence that they are) since this way I can learn in a much faster pace to make good requirements.
To build on the example from https://news.ycombinator.com/item?id=12428337: If another person says "MySQL" it is MySQL and nothing else. If they meant something different, he would say "data store" or give some non-technical description from which a technology-minded person can reconstruct what the person really wants. The same holds for the "submit button". If the person talks about a "submit button", such a button is meant. If he means something else, he would give a description, say "a user interface element which allows to send the data that I have inputted to the central data store such that [...] Choose the technology which is best according the current UI/UX guidelines.".
If I don't know what I want I give the information in a high-level way such that an expert can reconstruct/build the missing details. If I say some concrete technology that is an exact specification. If this is not what you want, it is lying. There is no in-between.
Customers have a problem to solve, and try to ask for something to solve that problem. Understanding the problem and proposing a solution (and a price) is how you get happy customers.
https://youtu.be/BKorP55Aqvg is a great example of how to fail at this. The "expert" totally fails to understand the customers needs, and instead gets hung up on bad definitions. He's supposed to be the expert in drawing lines, so he should be able to understand why they need them. You could say the customer is lying about their requirements, but they probably just don't understand them.
This goes for any customer/provider relationship - internal services, it departments, platform enginners. Not just selling stuff to other companies.