I confirm that upgrading PCRE2 does not produce the "Regex version mismatch" warning any more.

SELinux is preventing gdm-wayland-ses from write access on the sock_file bus.
SELinux is preventing systemd-user-ru from unlink access on the sock_file bus.

The above warnings from version 35.9 disappeared ... The below journal entries appear with version 35.10 :

systemd-tmpfiles[980]: Failed to create directory or subvolume "/var/lib/cni/networks": Invalid argument

systemd-tmpfiles[980]: Failed to set SELinux security context system_u:object_r:container_var_lib_t:s0
for /var/lib/cni/networks: Invalid argument

This update broke a local policy module I have:

# semodule -i smfs.pp
Problems processing filecon rules
Failed post db handling
Post process failed
semodule:  Failed!

Module:

# more smfs.fc smfs.if smfs.te
::::::::::::::
smfs.fc
::::::::::::::
/usr/sbin/smf-sav   --  gen_context(system_u:object_r:smf_sav_milter_exec_t,s0)
/usr/sbin/smf-spf   --  gen_context(system_u:object_r:smf_spf_milter_exec_t,s0)

/var/run/smfs(/.*)?     gen_context(system_u:object_r:smfs_milter_data_t,s0)
::::::::::::::
smfs.if
::::::::::::::
## <summary>Smart Mail Filter milters</summary>

########################################
## <summary>
##  "Smart Mail Filter" suite variant of milter template.
## </summary>
## <param name="milter_name">
##  <summary>
##  The name to be used for deriving type names.
##  </summary>
## </param>
#
template(`smf_milter_template',`

    milter_template(smf_$1)

    # Milters remove any existing socket (not owned by root) whilst running as root
    # and then call setgid() and setuid() to drop privileges
    allow smf_$1_milter_t self:capability { setuid setgid dac_override };

    # Look up username for dropping privs
    auth_use_nsswitch(smf_$1_milter_t)

    # Allow communication with MTA over a unix-domain socket
    # Note: usage with TCP sockets requires additional policy
    manage_sock_files_pattern(smf_$1_milter_t, smfs_milter_data_t, smfs_milter_data_t)

    # Config is in /etc/mail/smfs/smf-*.conf
    mta_read_config(smf_$1_milter_t)

    # Create other data files and directories in the data directory
    manage_files_pattern(smf_$1_milter_t, smfs_milter_data_t, smfs_milter_data_t)
')
::::::::::::::
smfs.te
::::::::::::::
policy_module(smfs, 0.0.9)

########################################
#
# Declarations
#

smf_milter_template(sav)
smf_milter_template(spf)

# /var/run/smfs is shared by smf milters
type smfs_milter_data_t, milter_data_type;
files_pid_file(smfs_milter_data_t)

########################################
#
# smf-sav local policy
#

allow smf_sav_milter_t self:netlink_route_socket rw_netlink_socket_perms;
allow smf_sav_milter_t self:tcp_socket create_stream_socket_perms;
allow smf_sav_milter_t self:udp_socket create_socket_perms;

# It makes outbound SMTP connections to verify addresses
corenet_tcp_connect_smtp_port(smf_sav_milter_t)

sysnet_read_config(smf_sav_milter_t)

########################################
#
# smf-spf local policy
#

# (no additional policy needed - template is sufficient)

Module had been unchanged for years. Downgrading selinux-policy back to selinux-policy-35.9-1.fc35 and reinstalling the module fixed it.

I am trying to figure out what could possibly go wrong and create a new build as soon as I find the root cause.

@clnetbox, I managed to sucessfully update flatpak to flatpak-1.12.4-1.fc35.x86_64.

@zpytela I tried it again after rebooting the system - same results - didn't work. What I didn't mention before,
the upgrade process to 35.10 took a way longer time as usual, and also a lot of SELinux warnings popped up.
The last version that worked properly without any noticeable issues was 35.8 ... at least for me. To sum it up :

New issues after upgrading to version 35.9 ->

SELinux is preventing gdm-wayland-ses from write access on the sock_file bus.
SELinux is preventing systemd-user-ru from unlink access on the sock_file bus.  

New issues after upgrading to version 35.10 ->

SELinux is preventing dnf from using the mac_admin capability.
SELinux is preventing restorecon from using the mac_admin capability.

systemd-tmpfiles: Failed to create directory or subvolume "/var/lib/cni/networks": Invalid argument
systemd-tmpfiles: Failed to set SELinux security context system_u:object_r:container_var_lib_t:s0 for /var/lib/cni/networks: Invalid argument  

The update took longer because of recompiling the policy files because there was an accidental upgrade of pcre2 in the same RPM transaction.

This needs to be reversed urgently before it breaks more installs.

It can't. Already in stable.

@zpytela I suggest you remove versions 3.9 and 3.10 from stable until all issues are finally fixed in the new version.
flatpak-1.12.4-1.fc35.x86_64 (testing) depends on selinux-policy 3.9 being installed, that should be reverted as well.

A new selinux-policy package is being worked on and will be ready soon.

Also tried semodule -nB:

# semodule -nB
Problems processing filecon rules
Failed post db handling
Post process failed
semodule:  Failed!

# semodule -nBv
Committing changes:
Found conflicting filecon rules
  at /var/lib/selinux/targeted/tmp/modules/100/miscfiles/cil:46
  at /var/lib/selinux/targeted/tmp/modules/200/cockpit/cil:919
Problems processing filecon rules
Failed post db handling
Post process failed
semodule:  Failed!

@clnetbox the update was pushed stable because it had an autopush threshold of +3 feedback (the default). It got 3 positive feedbacks with no negatives (from xvitaly, ppisar and drepetto), so it was pushed. Now it's pushed it cannot be "removed from stable", that's just not a thing in Fedora; it has to be replaced with a higher-versioned update that works.

@zpytela it might be a good idea in future to set a threshold of +5 or higher for selinux-policy updates. Just about everyone has it installed, so you shouldn't have a problem with getting enough feedback on a working update, but it would help avoid situations like this where there's a bug that may not be obvious to the first three people who test.

Also, the update did actually cause a couple of openQA tests to fail, but it seems neither of those tests is in the greenwave policy so they didn't cause the update to be gated. At least one of them definitely should be in the gating policy, so I'll update that.

A new update is available now: FEDORA-2022-87a0b7e8d0

Sorry for all the troubles.

@adamwill, this is what I usually set: +5 and -2, unfortunately forgot to change it this time. I am also about to take some measures to prevent from big problems like this, but as you see neither I nor other users nor our CI tests found any problem.

Thanks for the information @adamwill ! The new version 35.11 seems to work without issues.
If I understand you correctly, all users who update their systems will run into heavy problems
until version 35.11 will be pushed to stable. Hope we get enough positive feedback very soon.

@clnetbox, more accurately it should rather be all users with the cockpit-ws package installed who installed v35.10

@zpytela the update seemed to cause problems not related to cockpit as well. the openQA tests that failed were related to podman and FreeIPA. the cockpit tests all passed. I'll see if 35.11 passes the tests that failed on 35.10.

selinux-policy-35.10 contains a rule which duplicates one in cockpit-ws, after the update none of the custom modules is active, causing the software not work

so it should not happen on systems without cockpit-ws, but affects many services

Ah, I have cockpit-ws installed since I'm using Fedora Server, and that's what broke things even though I'm not actually using cockpit myself?

@pghmcfc exactly, the unfortunate selinux-policy clashed with the installed cockpit selinux module, either cockpit was active or not