Please explain to me how this works for the case I outlineed, eg:

        some_function(arg1, arg2, arg3, arg4,
                      arg5, arg6);

For the sake of argument, say tabstop=4. If the first line starts with two tabs, will the second line also have two tabs and then a bunch of spaces, or will it start with five tabs and a couple spaces?

You wouldn't use an alignment-based style, but a block-based one instead:

  some_function(
      arg1,
      arg2,
      arg3,
      arg4,
      arg5,
      arg6,
  );

(I don't know what Go idiom says here, this is just a more general solution.)

Checking the original code on the playground, Go just reindents everything using one tab per level. So if the funcall is indented by 2 (tabs), the line-broken arguments are indented by 3 (not aligned with the open paren).

rustfmt looks to try and be "smarter" as it will move the argslist and add linebreaks to it go not go beyond whatever limit is configured on the playground, gofmt apparently doesn't insert breaks in arglists.

You should NOT do such alignment anyway, because if you rename "some_function" to "another_function", then you will lose your formatting.

Instead, format arguments in a separate block:

    some_function(
        arg1, arg2, arg3, arg4,
        arg5, arg6);

When arguments are aligned in a separate block, both spaces and tabs work fine.

My own preference is tabs, because of less visual noise in code diff [review].

In an ideal world, I'd think you would put a "tab stop" character before arg1, then a single tab on the following line, with the bonus benefit that the formatting would survive automatic name changes and not create an indent-change-only line in the diff. Trouble being that all IDEs would have to understand that character, and compilers would have to ignore it (hey, ASCII has form feed and vertical tab that could be repurposed...).

Or you could use regular tab stop characters to align parts of adjacent lines. That's the idea behind elastic tabstops: http://nickgravgaard.com/elastic-tabstops/

Not all editors, however, support this style of alignment, even if they support plugins (looks at vim and its forks).