Sorry about the vagueness. I was afraid my post was too long already, and wanted to see what info was requested before spamming everything I could think of. I also felt there was some simple thing I was missing and hoped someone could provide some clue based on what I wrote. And in fact there was such a thing, and your response had a clue toward it. 

I was missing one key difference between my btrfs subvolume layout and the standard one that SUSE_BTRFS_SNAPSHOT_BOOTING was expecting. I have my / mounted from a subvolume @ whereas the standard one mounts the btrfs root to /. Realizing this made the error message finally make sense to me.

I was able to get grub working again by running the grub2-mkconfig and grub2-install with SUSE_BTRFS_SNAPSHOT_BOOTING disabled from a chroot from a LIVE usb boot. I'd thought I'd tried that, but must have not had all the right pieces in place in the several variations of that I tried.

Anyway, thanks for your response Andrei!

On Sat, Jan 29, 2022 at 7:10 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On 29.01.2022 08:58, Eric wrote:
> In short: I added btrfs subvolumes (including @/boot/grub2/x86_64-efi ) to
> try to get snapshot booting in the grub2 menu to work, and after running an
> update grub fails to the recovery console and reports
>
> error: ../../grub-core/fs/btrfs.c:1997:file '/boot/grub2/x86_64-efi' not
> found.
> error: ../../grub-core/fs/btrfs.c:1997:file
> '/boot/grub2/x86_64-efi/normal.mod' not found.
>
> From the grub rescue prompt I can
>
> ls @/boot/grub2/x86_64-efi
>
> and it successfully reads that folder. Why can it see this path with the @
> and not without the @


Because they are two different paths.

> and how can I fix this?
>

Honestly? The most simple and straightforward is to reinstall with snapshots enabled.

> ---------------------
> Longer version
>
> My openSUSE system only had a @ subvolume for / and a @home subvolume
> (which was not a child of the @ subvolume, but a sibling, FWIW). To try to
> get the grub menu snapshots working, I created subvolumes for /var
> /usr/local /srv /root and /boot/grub2/x86_64-efi, copying over the contents
> of the directories they would replace and then moving the subvolumes into
> the place of the old directories

That is not how openSUSE subvolumes are organized normally when snapshots are enabled.
I cannot say whether this can confuse tools or not.

> (using single user mode for a couple of
> these such as /var), and added /etc/fstab entries for them. I did a few at
> a time, rebooting in between to make sure things were working properly. I
> added SUSE_BTRFS_SNAPSHOT_BOOTING=true into /etc/default/grub and made sure
> grub2-snapper-plugin was installed. The system booted fine after all of
> these changes but I hadn't refreshed grub.
>
> At this point I ran a full zypper update, since I was overdue, figuring it
> would take care of the grub refresh. And I guess it did, but now grub is
> broken.
>
> I've booted with a usb LIVE image and set up a chroot to run grub2-mkconfig
> and grub2-install to try to fix it (including once with
> SUSE_BTRFS_SNAPSHOT_BOOTING disabled again) but I still get the same error.
>

So start with showing at least some facts about your system, not vague description.
Output of following commands would provide some initial information

btrfs subvolume list /mnt
btrfs subvolume get-default /mnt
cat /mnt/etc/fstab
efibootmgr -v
cat /boot/efi/EFI/opensuse/grub.cfg
grep -v '^#' /mnt/etc/default/grub

Here /mnt - whatever path you mounted you btrfs root on. /boot/efi refers to *your*
ESP that is used in your system. You may need to mount it in live environment.