A few years ago, when we wanted to convert a Microsoft Office Word document (.doc) to a Acrobat .pdf file, we would use Export from the sub-menu accessed from File. Then as time went by, we had the choice of installing plug-ins so that the pdf generation is done by choosing to print the document with a virtual printer (which is essentially a converter). Now in newer versions of Microsoft Word, we can just use Save As, which allows us to save the doc to a pdf with a list of file types.
I used the word convert/converter because this is a word of abstraction and it can apply to both the mechanical mode and mental model of this action. But for the actual terms o Export, Print, and Save As, which one is closer to the mental model of the users?
This action is to convert a .doc file to a read-only, uniformly-formatted, and annotation-less new file. Imagine Export as a process performed by a big machine which converts the data to another form of data. In early days, the mechanical model of this is close to what the user have in mind because the user imagine computers as mysterious and intelligent machine. Print is closer to the actual use of printing out a physical paper version of the document so it is read-only and meant to be distributed to other project members, which is a perfect example of mechanical model, but also was close to the mental model of it because people think pdf is meant to be made like a printed, clean document. As pdf becomes more commonly used across platforms and occasions, this conversion is nothing more than making it a new file-type, which is both how the mechanical and mental model works in this case.
I agree with Cooper that the closer the representation model is in-sync with the mental model the better the design. But in this file conversion case, based on my observation, there is nothing wrong with making the functionality echoing with the mechanical models because our mental models just have the abstraction of the idea which can be interpreted and evolved with the mechanical models.