These generally look reasonable to me, some thoughts inline. In some of these cases I think we can probably just remove extra references to "this install", "this install of Phabricator on this server", etc., and let it be implied by context.

This is just trying out some changes that modify the language to reduce instances of "Phabricator" from user-visible text. I went through the auth provider implementations to try out using "platform", "server", "service", and in one case I think just "instance".

argh

I caught one cosmetic issue in D21711, but this works properly for me locally now. Thanks!

I ran into this while trying to reproduce the issue:

The stalled transactions on this host published after I deployed the update.

These keep springing up

(After picking up D21697, the approach works properly in my environment where I originally ran into this, but there are a couple of rebase calls still present in ArcanistMercurialLandEngine that don't use the new API yet.)

I just use TextMate, which is a fairly lightweight editor. I have it minimally configured to disable a couple of default behaviors and add a couple aliases, and I have a crude "jump-to-definition" script set up that tries to open whatever file defines the class/function under the cursor and succeeds about 95% of the time.

Do you use an editor like PHPStorm or WebStorm? So far I've been using SublimeText and ripgrep as the primarily tools.

...the one with --onto-remote default not appearing in the trace output...

• Updated the MercurialMarkerQuery to use a similar execPassthruWithExtension(). This results in printing the execution with --trace and better encapsulates the functions handling the extension-enabling details.
• Made newConfiguredFuture() to combine the environment/cwd configuration for mercurial executions.
• Updated to store result of func_get_args() into a variable first instead of passing directly into a function call.
• Updated comments.

Oh I forgot to include that it does launch the regular local version of arc-ls-markers in my sample output, which may have provided more context for my comment about the one with --onto-remote default not appearing in the trace output

...or did you mean something else?

Specifically the arc-ls-markers which uses the --output argument, which appears to only be used when a remote marker is specified for landing. That uses $api->newPassthru(). When checking the output from arc land --onto-remote default it doesn't appear to log the execution of the passthru.