That would work.

I’m not sure what could be in (or missing from) your environment that would break sudo, but it’s a place to check at least.

This goes a little beyond me because I have no idea how gdm would differentiate Xorg or wayland sessions.

Look into the session files themselves (.desktop) - they have an Exec= line. Then see if that’s maybe just a shell wrapper around something else, e.g.: file /usr/bin/sway and see what it does.

That’s all I have.

(Why are there % signs)

Good question, here’s the explanation man sudoers offers:

The definitions of what constitutes a valid alias member follow.

       User_List ::= User |
                     User ',' User_List

       User ::= '!'* user name |
                '!'* #user-ID |
                '!'* %group |
                '!'* %#group-ID |
                '!'* +netgroup |
                '!'* %:nonunix_group |
                '!'* %:#nonunix_gid |
                '!'* User_Alias

       A User_List is made up of one or more user names, user-IDs
       (prefixed with ‘#’), system group names and IDs (prefixed with ‘%’
       and ‘%#’ respectively), netgroups (prefixed with ‘+’), non-Unix
       group names and IDs (prefixed with ‘%:’ and ‘%:#’ respectively),
       and User_Aliases. Each list item may be prefixed with zero or more
       ‘!’ operators.  An odd number of ‘!’ operators negate the value of
       the item; an even number just cancel each other out.  User
       netgroups are matched using the user and domain members only; the
       host member is not used when matching.

TL;DR % lets the system know the following word is a group name, instead of a username

In that case Ubuntu DOES things differently. And weirdly imho, there’s no reason for the normal user to be in the root group since they still need privilege escalation to edit system files.

If you use visudo to edit /etc/sudoers you don’t have to worry about the syntax.

FWIW, this is what my perfectly healthy system looks like:

$ sudo grep -vE '^[[:space:]]*#|^[[:space:]]*$' /etc/sudoers
Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults	use_pty
root	ALL=(ALL:ALL) ALL
%sudo	ALL=(ALL:ALL) ALL
@includedir /etc/sudoers.d

$ groups
a_norny_mousse adm dialout fax cdrom floppy tape sudo audio dip video plugdev netdev bluetooth lpadmin scanner

You will notice that my user is in the sudo group; this is enough to give them admin rights as per sudoers.

You run it and then reboot. If that doesn’t fix it, then it didn’t fix it :\