Some of the (3), (2), (1) stuff is that we're trying to pick a single behavior which addresses most use cases reasonably well. For example, if we use "natural" bookmark names that will tend to make things much worse for users in bucket (3).

T3277 (arc cleanup, to delete all the patch branches/bookmarks) is another approach here, and that "can't" work if we use "natural" names.

I'm not hugely sympathetic to this class of use case because "match patterns in a block of text, then run commands using the matches" seems like a problem that full-time professional software engineers should have the skillset required to overcome handily, and that this should be a problem which takes less time to fix yourself than to complain to someone about.

I think we're likely to start retaining some sort of .arcmetadata about working copies (some discussion in T3875) and begin recording invisible information about branches and bookmarks. On one level I dislike this -- currently, the behavior of arc is mostly just a function of the working copy's state, not "working copy" + "invisible external magic you can't see". However, I think the balance of feedback is that users would like more magic here.

If we magically new that branch apple was created by arc patch but branch banana was not, we could selectively clean up apple during some kind of arc cleanup operation, which would free us up to use "natural" branch names.

But I think any path forward here needs to wait for the next arc iteration.

The other general force here is that I'm very resistant to adding options, and especially resistant to adding config file options. Perhaps this is something we should look at embracing more readily in the next iteration.

And auto-dependencies are unambiguously desirable and covered by T11343, yeah.

For (1), it is expected to not apply bookmarks to dependency changesets that are applied as part of the patch issued? When patched one-by-one they would each obtain their bookmark.

For (2), I don't see the leap in that using "natural" names requires metadata tracking - does existing arcanist features currently rely on identifying arcpatch- bookmarks?

I'm not hugely sympathetic to this class of use case because "match patterns in a block of text, then run commands using the matches" seems like a problem that full-time professional software engineers should have the skillset required to overcome handily, and that this should be a problem which takes less time to fix yourself than to complain to someone about.

To be fair there were scripts being used before I was told about the issue; I had walked into a conversation where one developer was discussing with another that they end up with excess bookmarks and the other was telling them were to get a script they made. I tried to interrogate to understand what they were doing but I couldn't quite follow what their workflow was that they ended up with all these bookmarks. They mentioned previously trying to have arcanist work with Mercurial's mqueue -- it sounded like they are working with multiple (dependent?) commits which do not overlap (no merge conflicts) and in order to switch between them they do lots of diffing and patching. I need to find out more about this though.

For (1), it's currently expected, yes. We don't create branches for dependencies in Git either, currently. I don't think this is terribly unreasonable, but I'm also not sure it's terribly useful (does it just help you keep track of which commits are part of the leaf?) and it makes cleanup more difficult by creating more total branch/bookmark artifacts in the local working copy.

For (2), we don't currently rely on the naming, but a theoretical arc cleanup would, and any scripting users currently use almost certainly does. If we move away from this, cleanup becomes essentially impossible without metadata tracking. It also makes cleanup more important, since all the garbage no longer collects itself in a big block of "arcpatch-..." stuff. So if we started using natural names without introducing metadata, we'd be making the existing cleanup problem worse.

None of this is a major concern -- I think if we introduce metadata these problems reduce to just problems of how many options/settings/preferences we want to have.

I missed your question in (1). A typical scenario for this would be when working on a feature which requires some refactoring work to be done. A revision is created with just the refactoring work and then a dependent revision is made which includes the actual feature work. During feature work additional refactoring might be made and need to update to that changeset and either add/amend changes, rebase the dependent revision back on top. Having the bookmarks auto created would help especially when using arc:bookmark when updating revisions back to phab.