Assuming that the example you gave was merely illustrative and that you are interested in the more general question:
The interesting thing about this question is that it reveals how many things can be assumed inside task dependencies. Dependency should be a matter of demonstration, not decision/power. If it isn't, then it seems there are problems elsewhere.
Maybe it's not clear what task A produces that is required for task B, or maybe it's not clear why task B requires that thing that task A produces. Maybe the granularity of the tasks is incorrect, and task A should be broken into two or more, only some of which might have a F-S relationship with task B.
The other thing that raised my eyebrows is that this is being challenged after execution has already begun. How was the plan baselined? Shouldn't this discussion have happened during the review of the plan? Why is the customer challenging the dependency now? This seems like there is an underlying problem.
Is the project behind schedule, or is the customer unhappy with the planned schedule because of external factors that have changed? If so, maybe the project needs a global replan.
Has some downstream dependency emerged that had not previously been called out? eg, does some other group need the result of task B in order to do their work? If so, can this be handled as a granularity issue, ie, refactor task B into smaller tasks, one of which can produce the needed thing?
How to avoid these discussions: I think it's okay and even desirable to have these discussions during plan review, before the plan is accepted and baselined. That helps avoid having them later, when they are more disruptive to the project. But the focus should be kept on products and requirements, rather than ownership and control.
Sometimes plans have to be changed, and schedules have to be updated. I'd think the important thing is to review the plan systemically, to be sure you've identified all the actual problems, rather than quickly and narrowly focusing on responding to the particular local item that is raising objections. That particular dependency may be a symptom rather than a cause.