Some commands needed modification to do something sensible in a multi-parent workspace. Here I've categorized all of the documented commands (i.e. those visible in mtn --help) with some notes on what changed and why.

Commands which have been updated to error out, and why

diff:: Requires at least one -r argument.  Without an -r, what should we base the diff on?  Left or right parent?  The "base merge"?  Revisit this after users are more engaged and we know what conflicts look like.
revert:: The question is where to revert to; possibilities are similar to diff, plus there's a question of whether/when revert should undo the merge operation.
update:: not worth even trying to figure out what the semantics should be.
merge_into_workspace:: A revision can't have more than two parents.
automate get_base_revision_id:: scripts expect just one id, but logically it should return two.  *(njs: a fully canonical answer to this may have to wait until we work out exactly what conceptual model we want to use for workspace merges.)*
automate inventory:: needs a format change to deal with more than one parent. *(njs: ditto)*
automate attributes:: emits info about changed attributes, therefore there is a question of which parent that should be relative to.  *(njs wonders if we can just ditch that part of it, but suspects tommyd wants to keep it.)*
annotate:: Requires an -r argument.  This is not because there's any question what it ought to do without one, but rather because the annotation engine is not prepared to deal with revisions that aren't in the database.  This is a bug for both single- and multi-parent workspaces (consider the case where you have modified but not committed the file you are annotating) but is only lethal in the multi-parent case.

Commands which have been updated and work

• add, drop, rename, pivot_root
• attr
• pluck
• commit
• get_roster
• automate get_revision
• automate get_manifest_of
• automate get_current_revision_id
• status ''(shows separate deltas vs. both sides; script authors are reminded that they should be using automate get_revision (which itself will now do things it didn't used to, but the format always allowed the possibility). Should eventually show conflicts specially.)''
• log (without command line arguments, follows both parents, just as it would for a merge node already in the database)
• list known/unknown/missing/ignored
• list changed (lists everything changed relative to either parent in one jumble, no distinctions made)
• refresh_inodeprints
• migrate_workspace

Does not operate on a workspace

Starred commands in the list below will have their semantics change later in this process, but are not affected at the present stage.

     approve
     automate ancestors
              ancestry_difference
          certs
          children
          common_ancestors
          descendents
          erase_ancestors
          get_file
          graph
          heads
          interface_version
          keys
          leaves
          packet_for_fdata
          packet_for_fdelta
          packet_for_rdata
          packets_for_certs
          parents
          stdio
          tags
          toposort
     cat
     cert
     checkout
     comment
     chkeypass
     complete
     cvs_import
     db (all)
     disapprove
     dropkey
     explicit_merge (*)
     fdiff
     fload
     fmerge
     genkey
     heads
     help
     identify
     list certs/keys/branches/epochs/tags/vars
     merge (*)
     merge_into_dir (*)
     privkey
     propagate (*)
     pubkey
     pull
     push
     rcs_import
     read
     serve
     setup
     set
     show_conflicts (*?)
     sync
     tag
     testresult
     trusted
     unset