Being a software developer in an enterprise is often like being Top Gear's James May when he has to explain something to Jeremy.
But what usually happens when these meetings go bad is that the client is just not very good at expressing what they really want, but try to use technical terms anyway. The engineer gets hung up reacting to and debating the literal possibility of what they heard, instead of treating it as an exercise in translating from an alien tongue.
Edit to add: This is where agile/rapid prototyping can help too. Imagine coming back to this client a couple days later with a red cross on a piece of paper and saying, "The 3rd line is pointing straight at you, so you just see the end--this point here in the middle. And you can't see the other lines because they've been deployed into the 4th, 5th, 6th, and 7th dimensions to maintain perpendicularity. Now let's test some business scenarios." It might turn out those other lines were not needed at all. Or some user testing might show that the color actually does not matter. Etc. (I love to play with bad metaphors.)
Did we watch the same video? In what way did you interpret the character's behavior as trying to "squirrel away knowledge?"
