Correct, that's what I meant to imply in the first part of my comment. When I research new games I do that from a web browser and that's when I care about Proton status the most so this works great for that. It does not help when using the Steam client.
I tend to do my Steam shopping in the browser and I use the ProtonDB-Peek userscript. This gives a ProtonDB status badge in the right column under the review links.
Not sure what's causing the UI issues but another way to go about this is to create a custom collection and configure your browser to use it. This way you can control what shows up in "recommended". IIRC you have to use nightly, beta or a custom build like Fennec to allow using a custom collection.
I personally welcome this decision. I am fairly happy with the current syntax and I enjoy the explicit "does what it says" nature of Go code. None of the proposed alternatives would have made error handling more robust, they were pure syntactic sugar with no nutritional value.
Saying no to multiple proposals when you feel that the status quo is better can be difficult to do and I am happy that the Go team is able to make these kinds of decisions.
In the subject you wrote "successful full sys update" but the script and the other suggestions I see so far don't actually handle the "successful" part.
The log message only tells you that the update was started and the db mtime only indicates that the db was touched without saying anything about success.
I'd go about this by always performing the updates through a wrapper script that could check the exit status of the pacman or yay command and record a timestamp accordingly.
My first WWW experience was trying Mosaic on a computer without an Internet connection. I knew what the Internet was, we had access through an X.25 PAD (kind of like a dial-up shell session, no direct TCP/IP) so I'd already used IRC, Usenet, FTP, Archie, Gopher etc. I also knew what hypertext was from various local help and document browser programs. So I figured out that Mosaic can display HTML documents but of course without Internet connectivity just showing some local demo pages didn't seem all that special. But I figured it out later on...
[ 5067.696] (II) Applying OutputClass "AMDgpu" to /dev/dri/card1
Make sure that you actually have permission to that /dev/dri/card1 device. This may be arranged by udev or "video" group membership.
Regarding AMD vs Nvidia, unless you need CUDA you probably made the right choice. This sounds like a config issue and you'd probably be dealing with the same thing with Nvidia too.
You'd play the YT videos outside the browser using mpv in combination with yt-dlp and an mpv lua script would do the translation locally using the Bergamot engine (which happens to be Mozilla's translation engine). Could be adapted to use other engines too.
I am pretty that's the minibuffer-prompt face. But that's on the "already tried" list so not sure why that didn't work.
(custom-set-faces '(minibuffer-prompt ((t (:foreground "yellow" :weight bold))))) does the job for me.
Edit: oh yeah, as others have already mentioned it might also come from default. Other faces inherit from default so for example with the settings above you'd still inherit :background from default since we are not overriding it.
I'd add the language specification. It is well written and Go is a relatively small language so the spec is not difficult to digest:
https://go.dev/ref/spec
And pretty much everything from the official documentation page is a good read:
https://go.dev/doc/