You can pull the change directly by revision/diff id, using techniques documented at https://secure.phabricator.com/book/phabricator/article/harbormaster/#change-handoff, and have the Merge Manager in-charge of the merge, instead of the diff author; Your API call will instead initiate the merge instead of suggest a magic location for the push.

You could then add a "Send this Revision to the Merge Master" button on the revision page, which will make the API call.

Hm, interesting. I see a few problems with that technique, though:

1. It requires that an arc diff have always been run to capture the latest version of the changes. I foresee a not-uncommon case of developers amending one last change in, then attempting a land — but having all changes since their last `diff silently dropped.
2. It does no local branch management. Current arc land is quite useful in removing branches once they have landed.
3. It doesn't do a local rebase first. The local rebase not uncommonly catches conflicts — which are impossible for the merge manager to handle cleanly.

Most developers are used to landing their code from the command line, so the button isn't a clear win. By the time one implements an arc workflow that deals with fetching the remote to ensure it is up-to-date, rebasing appropriately, calling arc diff, making the API call, and removing the local branch, one has re-implemented essentially all of arc land.

Can the remote be a magica-virtual ref (Like gerrit's /refs/for/branch), so the API call complexity is removed?

How does removing the API call simplify matters? One still needs to have code to construct the name of the ref to push to (even if that's just a string concatenation). Doing that computation on a remote machine, rather than locally, makes little difference.

Then locally, you would always push to the same place - just configure the remote.origin.pushURL to the server which does the merging.

The URL to push to is constant. The ref to push to, however, would depend on what one was merging into -- hence what I mean by needing to be computed. Implementing this would also require replacing all of git-receive-pack on the server side; pushing into refs named by the server allows the server to not worry about magically hiding that overlap. As is, the server can manage the refs as normal refs, which works effectively.

Though the actual code changes to accomplish this are minimal, I can believe that supporting this land-elsewhere model isn't in scope for core arcanist. However, implementing the built-in workflows as final with private accessors precludes both subclassing and delegation for extensibility. Are there any good options available for implementing this, besides (a) local overrides to core land in our fork, (b) copying large swaths of code into new workflows, or (c) altering the final nature of the classes in our fork to allow them to be subclassed?

I can't think of any good solution right now, other than forking arc / duplicating the code; Forking is not in itself a bad practice - it's the most extreme form of "configurablity", although it comes with a price.
ArcanistGitLandEngine is less than a week old; I'm not sure how it will grow.

personally, I think T182 will become the common way to land things, and it will end up offering more flexibility for installs to customize what "Land" actually mean. I think users will prefer this to using the CLI, and OPs will prefer this centralized approach (No chasing users to upgrade their arc), which will make arc land less likely to allow full customization.