One of the big advantages, at least from my own perspective, that git and mercurial have over Perforce is that you deal with branch versions instead of file versions. When a git user asks, "What version is my workspace at?" it's trivial to get a correct and useful answer. This is not the case with Perforce. Perforce allows the user to sync subsets of files to different versions within a single workspace. This flexibility may sometimes be appreciated, but in general it's more trouble than it's worth. The success of git and mercurial should be evidence that, in 99% of use-cases, people don't need this flexibility.
Users regularly ask me, "How can I see what label my workspace is synced to?" For us, labels always version files from a single changelist, so they would be inconvenienced but maybe still happy if Perforce could answer the question, "How can I see what changelist my workspace is synced to?" Perforce even has trouble with that question, however. Pointing the user to http://answers.perforce.com/articles/KB/3458 makes everyone involved sad.
I think this situation could be resolved with an option in the workspace to lock all revisions of files in the workspace to a common changelist. If the user had this setting enabled and tried to sync a subset of files to a different changelist, the operation would fail. If instead the user tried to sync the entire workspace to that different changelist, the operation would succeed.
With that feature in place, 'p4 have' could be augmented to be able to take advantage of this and report a nice and clean @changelist for the entire workspace. P4V could be augmented accordingly to display this information to the user. Finally, Swarm could be augmented, especially for pre-commit reviews, to display the base revision from which the proposed changes were made.