Are you using the release_2gp_beta flow? That flow has extra steps to publish the release artifacts as tags and a release in the repository. Those artifacts are what ci_beta is looking for. If it doesn't find a beta since the last production, it uses the last production.

The documentation for releasing 2GP packages walks through the workflow built into CumulusCI for creating betas and publishing the artifacts:
https://cumulusci.readthedocs.io/en/stable/managed-2gp.html#create-a-beta-version

I'm not sure this is a bug. It may be a documentation usability issue, but the ci_beta flow's job is to install the latest beta published by either release_beta for 1GP or release_2gp_beta for 2GP.

@jlantz thank you for clarifying. I was extracting the create_package_version step from the release_2gp_beta flow because I didn't want to create a release/tags in GitHub for every 2gp beta version since I am using this for nightly builds.

If the goal here is to deploy and package the contents of our main branch each night and make sure no tests fail is release_2gp_beta followed by ci_beta the approach that you'd recommend? Or do you think using one of the feature flows would make more sense?

CumulusCI's default process, which I'd also recommend, is to create beta versions whenever a pull request is merged using release_2gp_beta and then running ci_beta to test the beta in a new scratch org. The idea is to test any changes to branch staged on the release train, generally main. The beta tags are prefixed differently and the releases are set as prerelease versions so GitHub will highlight the latest production release.

Note that release_2gp_beta does include github_automerge_main which will merge the newly built commit down to all feature branches that don't have it. You can disable but still keep the tag and release creation that with:

flows:
    release_2gp_beta:
        steps:
            4:
                task: None

Here's the reusable workflow for 2GP beta builds I've created in D2X:
https://github.com/muselab-d2x/d2x/blob/main/.github/workflows/beta-test-2gp.yml

Thank you @jlantz for clarifying the steps and explaining the intention behind the default process. I was curious at one point if the tags/releases might be what the ci_beta flow was counting on existing to find the latest beta. I think it could be helpful to others to clarify that in the documentation. I really appreciate you taking the time to help me with this! I'll go ahead and close this case and let you know if I have any further questions. 😄

I'll let the CumulusCI team review and close. I'm just a community contributor myself these days ;)

The source for all the docs is under the docs/ directory if you have ideas on where that information could be placed to be most helpful to someone coming from your perspective.