Top post here as it is the solution..

I once again have access to the computer. I have retried Andrei's suggestion:

snapper --ambit=classic rollback

It reported:

.stingray:/home/roger # snapper --ambit=classic rollback

Ambit is classic.
Creating read-only snapshot of default subvolume. (Snapshot 1407.)
Creating read-write snapshot of current subvolume. (Snapshot 1408.)
Setting default subvolume to snapshot 1408.
Client-side plugin '/usr/lib/snapper/plugins/10-sdbootutil.snapper' failed.
Server-side plugin '/usr/lib/snapper/plugins/10-sdbootutil.snapper' failed.
Server-side plugin '/usr/lib/snapper/plugins/10-sdbootutil.snapper' failed.

stingray:/home/roger # snapper ls

The three things that failed are not understood. I rebooted. And all seems good. I am where I was before the KDE6 adventure.

Although I am convinced I tried the command with --ambit=classic both before rollback (global option) and after (rollback option), I see in my history that I only ran the command with it as a rollback option. It was a stressful Monday. Sigh.

So, thanks all for the help. Especially Andrei who provided the solution.

I am still confused why the snapshots before 1405/1406 went away. They were there at one point when I rebooted. After the reboot they were gone. I see in my command history that I did not even reference earlier snapshots. Maybe they were too old. I do a zypper dup every couple weeks. So they could not have been too old. It looks to me like the snapshot cleanup logic will remove older snapshots so one finds oneself in the situation I was in: only one snapshot - making it difficult to use that snapshot for anything. Especially not a rollback. Unless you know about the mystical --ambit=classic option.

Anyway, I'm a happy camper. Once again, thanks all!

On Tue, Mar 19, 2024 at 5:00 PM Michael Spartana <furryllama@comcast.net> wrote:

On 3/19/24 09:25, Carlos E. R. wrote:
> On 2024-03-19 10:13, Roger Oberholtzer wrote:
>> On Mon, Mar 18, 2024 at 6:13 PM Darryl Gregorash <...> wrote:
>>     On 2024-03-18 07:12, Carlos E. R. wrote:
>>      > On 2024-03-18 13:49, Roger Oberholtzer wrote:
>>      >> >> after that. If I wasn't booted into it perhaps? Like boot
>>     from a USB
>>      >> stick and then try the rollback on this filesystem? I suspect
>>     I'm just
>>      >> demonstrating my ignorance about that it the reason for the
>> problem.
>>      >
>>      > You are just demonstrating one of my reasons for not using
>> btrfs :-)
>>      >
>>     Btrfs has nothing to do with this, except perhaps that Roger
>> would not
>>     have got into this mess if he didn't have snapshots available.
>>
>>     Of course, he could also have avoided it by first learning how to
>>     properly do a rollback.
>>
>>
>> I did the rollback correctly. Or at least it did not complain. I
>> have done this before when a zypper dup went astray.
>> But when I rebooted, I still had odd stuff from the failed zypper
>> dup. That I do not understand. I have never seen that before.
>
> Ah, the kde6 zypper dup.
>
> I heard that the desktop could crash during the procedure, halting the
> zypper process in its tracks and leaving a botched upgrade.
>
> The recommendation, a really old one that people has forgotten, is to
> run "zypper dup" in one of the virtual text consoles, not in graphic mode.

     That's what happened to me (tumbleweed) so then booted to iceWM and
then zypper dup'd and it worked.......

                         mikeS