I have always said If all the linux guys worked together instead of against each other unimaginable things could happen… and Microslop would have long be history. 
That would explain why i do not have the problem: i have long ago edited the vconsole file adding the right layout which was not set by default.
After the first reboot following this stable update, my Swedish 
keyboard layout was gone and had been replaced by the default US layout.
Actually, Keyboard Layouts had been disabled entirely, so I had to open System Settings → Keyboard and add the Swedish layout again before everything worked normally.
KDE Plasma (Wayland). I’ve never encountered this problem before.
Welcome to the forum! 
You need not have bothered “fixing” those permissions, because they have been wrong for years already, courtesy of the upstream developers of the bluez package not understanding the UNIX permissions system. 
Long story short… 
/etc/bluetooth is part of the bluez package.
The package insists on 555 permissions, i.e. dr-xr-xr-x.
The root account always has write access to anything residing on a read/write-mounted filesystem, regardless of the permissions. Therefore, 755 or 555 does not make any difference when the /etc/bluetooth directory is owned root:root — as it is.
Those comments in xsane AUR packages don’t tell the whole story. They only reflect the users’ perception, and show one possible workaround.
Actually, I see no removal of libjpeg.
As described on the project’s web page, libjpeg-turbo implements two interfaces: its own provided by /usr/lib/libturbojpeg.so and for compatibility, the traditional /usr/lib/libjpeg.so. Both are available before and after Manjaro’s July update.
What changed is that the updated libjpeg-turbo package does not announce this capability any more:
Before the upgrade:
$ LC_ALL=C pamac info libjpeg-turbo | grep Provides
Provides : libjpeg libjpeg.so=8-64 libturbojpeg.so=0-64
but after the update
$ LC_ALL=C pamac info libjpeg-turbo | grep Provides
Provides : libjpeg.so=8-64 libturbojpeg.so=0-64
Was this intended? From the libjpeg-turbo project’s web page linked above, I see no indication that the traditional libjpeg.so interface would become obsolete in any way, and no advice to convert to their own interface.
In fact, the above xsane user’s workaround would not change xsane to use the newer interface. It would only skip the blocking build issue, and xsane would still use the traditional interface anyway.
Other foreign packages are affected by a broken build too, like webcamoid (AUR) per its dependency libuvc. One webcamoid user suggested a different workaround: to add libjpeg.so to the dependency list. Which works, but brings its own problems 
.
Could it be that libjpeg was dropped from the libjpeg-turbo PKGBUILD file’s Provides line only by mistake?
BTW, good news:
this update solved the graphics issue with old Intel “Sandy Bridge” integrated graphics processors, that is still listed above:
With the update of mesa to 26.1.4, the issue is gone.
That worked. Thank you! However, this goes against Manjaro’s actual recommendation. Shouldn’t the recommendation be corrected then?
Now I have a new problem with my ThinkPad 450s. I wanted to update it as well. The update failed:
Fehler: Der Vorgang konnte nicht durchgeführt werden (In Konflikt stehende Dateien)
lightdm-gtk-greeter-settings: /usr/lib/python3.14/site-packages/lightdm_gtk_greeter_settings/__pycache__/installation_config.cpython-314.pyc existiert im Dateisystem
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.
Do I understand correctly that an existing file is blocking the entire update? Should I just delete it?
Mod edit: Corrected code formatting.
You could use the overwrite="/usr/lib/python3.14/site-packages/lightdm_gtk_greeter_settings/__pycache__/" argument to your pacman` command.
That is what i personally did, just deleted the pycache subfolder. One can do both.
I will correct the overwrite argument to be more specific in the solutions section.
A post was split to a new topic: External monitor no longer appears as an output device
Okay – I followed it. However, it only worked when I used:
pacman -Syu --overwrite="/usr/lib/python3.14/site-packages/lightdm_gtk_greeter_settings/__pycache__/*"
Then the updates went through.
Since I’m still new to Manjaro, I’d like to understand what happened here. Can someone please explain this to me?
Someone somewhere made a mistake…probably the pachager in arch, and not with this but with the previous version of this package. My theory: the cache was deleted, and then the package created without it. Now the new version is fixed and have this cache again, but pacman thinks those are foreign files since they were not there in its database (mistakenly) and refuses to overwrite without confirmation.
The change was intentional:
I’ve just checked System Settings → Keyboard before the update: they are already empty even though the keyboard does use the keymap of my locale.
So that emptying must have happened after a previous update.
After the update, my keyboard keymap is still fine, System Settings → Keyboard is still empty and “Keyboard Layouts” disabled and localectl status doesn’t show any change.
Update seemed to go ok. Checked for .pacnew files (nothing new). After a reboot only 1 monitor (I have 2 connected) is working and only at 1024x768. Did a restore via timeshift. No change.
AMD GPU (RX 7600)
xfce4
Self inflicted.
Did another timeshift restore (went back 2 days). That fixed everything.
The day before the upgrade, I did some cleanup and removed some package that showed up in ‘pacman -Qm’ output.
accounts-qml-module
linux-firmware-meta
mhwd-nvidia-570xx
mhwd-nvidia-575xx
electron34
Doing another sudo pacman -Syu and rebooting worked.
After this update my system doesn’t shut down correctly. I’m on KDE Plasma and when I use the menu to shut down or use the command poweroff in the terminal my system appears to shut down but my fans are still spinning and the LEDs are still on.
System specs:
Not just similar it seems to be really the same issue as happened for 6.3.6. Notice also
Everyone using Plasma and print-manager will be impacted. @philm please rebuild the package.
It’s likely related: I was notified of a .pacnew file very recently – when I merged it, the Swedish language was restored.
With which kernel?
@Kyoketsu9513, you may want to update your profile page. It says you’re running kernel 4.17. 
A post was split to a new topic: Suspend no longer working
I’m running kernel 7.1.3-1-MANJARO