Because of how antigen works, when it loads from the cache, at the point where it sources the plugin file, $1 is unfortunately set to apply [...].

That sounds like a bug.

Imagine if antigen exposed an API for running a command after compinit.

antigen run-after-compinit my-command

And imagine that it would invoke my-command with unspecified arguments. That would be a bug, right? It should invoke my-command and not my-command apply or anything like that.

The same logic applies to source. antigen should source without arguments. That is, instead of this:

source "$some_file"

It should do this:

set --
source "$some_file"

Is there a different variable that could be used other than $1? It seems like the current setting is an easy way to silently break things in unexpected ways.

Going back to run-after-compinit analogy, it's certainly possible to work around the underlying bug by never using positional arguments in my-command and instead using named global parameters. It is a workaround though. The right thing to do is to fix the bug in antigen.

I understand where you're coming from, but the fact that this bug exists in multiple plugin managers that we know of (both zgen and antigen) means it's probably more widespread and would be easier to fix here.

I'll have to see if I can wrangle up the antigen and zgen maintainers, but I'm not optimistic as zgen hasn't been updated in over 2 years and antigen hasn't seen any code changes during that time period either.

the fact that this bug exists in multiple plugin managers that we know of (both zgen and antigen) means it's probably more widespread

True. On the plus side, this bug doesn't exist in zplug and zinit.

and would be easier to fix here.

Here it wouldn't be a fix but a workaround. You are the first person to bring this up, so I suppose the number of users who would benefit from this workaround is small.

By the way, why do you care about antiques such as antigen and zgen? How did this issue come to your attention?

I've been using antigen in my config for a while - the reason this didn't show up right away is because I don't make it a habit to run the command to update my zsh bundles, so I only noticed this on a new install. I'd imagine plenty of other people are the same way. Anyway, after my new install, my theme stopped showing the git prompt (because it's only enabled if gitstatus_start exists).

At least to me, when sourcing a file I don't expect it to handle arguments and I especially don't expect it to rename functions based on an argument passed to a function outside the scope of that file. It took me a long time to debug this (actually multiple weeks since it wasn't super high priority, just an annoyance) because that behavior was the last thing I would have expected.

I've never been a fan of zplug, as I don't like that it invents a new syntax on top of zsh's for loading plugins... if I can't get antigen to work, maybe I'll have to try zinit. I liked antigen because it was fairly minimal and no-nonsense and has been stable for quite a while. Maybe one day I'll have to come up with yet another alternative.

I can add GITSTATUS_FUNCTION_NAME_SUFFIX and use it like this:

function gitstatus_start"${GITSTATUS_FUNCTION_NAME_SUFFIX-$1}"() {
  ...
}

Then you'll be able to set GITSTATUS_FUNCTION_NAME_SUFFIX="" in your config to explicitly disable name mangling. You'll probably be the only person to use this parameter.

Do you see any other workarounds that wouldn't break backward compatibility?

No, that's alright - don't add a workaround just for my sake. You're right that antigen/zgen should probably be updated anyway. I appreciate the offer though.