Mixed‑revision working copy: unclear revision reporting in Subversion

In Subversion a working copy is intentionally a mixed‑revision construct: after a commit only the committed paths advance, while the rest of the tree remains at the previous revision. The svn status command reports local modifications and, with -u, items that are out of date relative to the repository, but the revision number displayed for each path can differ.

For users who need a single, concise view of the checkout’s revision state, this design creates ambiguity. Existing tools such as svnversion provide a compact range (e.g., 123-456M) yet they are not integrated into the standard status workflow and do not offer a plain‑language description of the mixed state.

What is the intended interpretation of the revision numbers shown by svn status when a working copy contains multiple revisions? Is there a supported mechanism or flag that can return a single revision number (or a clear range) for the entire working copy, perhaps in a more user‑friendly format? Would adding a verbosity or human‑readable mode to svn status help resolve this ambiguity?