When you get requirements from your users, they're going to mix in how they think about the problem with how they think that problem should be represented in the program. The problem with that is that they don't know what computers can do, so they can't possibly be expected to know how the problem should be represented in the program. And in fact, the UI, which is the only thing they ever see, will probably be more task-oriented than representation-oriented, so they probably will never see how your program actually models the problem and therefore won't be able to suggest good changes to it.
Ultimately, though, there's an underlying mental model that the user is using for the task. And for most fields, there's really only one correct mental model, so I actually disagree that expert users have different mental models, at least not with significant differences.
Rather, listen to your users problems, listen to what they think a solution is, then let your design team determine if there is a better and more simple solution. Sometimes there may not be, but often there is.