For some of us with vision issues and have to deal with such things as grey text on a grey background, you wind up doing it a lot.

Wasn't Paul's website. Just mentioning it. It is an issue with the Blue GoG employee text though, on both backgrounds.

One Firefox add-on that enables you to bypass all "Left-click" and "Right-click" restrictions is the "Righttoclick" add-on. When you want to use it, just click on the add-on to activate. It automatically shuts off when you close your browser (if you didn't manually switch it off). This is different from the "Righttocopy" add-on that activates all the time and interferes with pages that use mouse javascript events.

Unfortunately, the add-on was officially removed by the author from the add-ons page. But you can download a back-up version from here.

https://www.pouar.net/downloads/righttoclick.xpi

Oh wow, I hadn't even thought of that! For me it's just something I do for reasons that I'm not sure I can articulate as it's almost entirely subconscious. I don't even notice I'm doing it unless someone blocks it like the blog from the OP. I think it might help me keep my bearings or something.

It does look like the contrast here on GOG is a bit low.

Well, that fucking sucks. I was already wary of 10.13 because of some other potential hiccups. With this news I might as well stick with macOS Sierra (10.12) in perpetuity, seeing as I currently have half of my GOG library installed through a mixture of Mac-native/Wine-wrapped/Boxer-ed titles (~500) - looking at the list of apps even some of my newer Mac-native games aren't 64-bit. ... It's not like my mini can even take advantage of the under-the-hood performance changes anyway. =/

Apple doesn't seem to care all that much about backward compatibility, which isn't exactly news as they have a history of charging forwards come what may. In some ways that is good because it stops legacy code from bogging down the system - hello, Windows! - but in the case of games maybe not so. At least it'll force devs to finally fully support 64-bit.

(This really isn't my problem, as I don't touch anything created by Apple, but...)

There are plenty of other options too.
ScummVM can run about 100 games with no problems. ResidualVM can run a couple more.

Then there are some random game-specific projects at various stages which may (or may not) help running older games. I really don't know the status of Mac versions, as I have practically speaking never touched a Mac, so keeping up with Mac ports hasn't been that important. I guess there could be some website for Mac gamers that lists those?

The bottom line is, at least for adventure gamers, things look kind of good no matter what. Fans of other genres may have a bit harder time, although at least some notable FPS games have some fan project ports to help run then on present day computers.

With rumours about Apple switching from Intel to ARM-based CPU in their Macs this should be the last thing you should be worried about. :p

I think this is good, long term. And I'm glad to know that OpenBSD isn't the only system around that doens't bow before the wicked lord of backward compatibility.

Of course it sucks for anyone affected, short term.

But there will be a solution eventually. Emulation, virtual machines, JIT recompilation -- there's a bunch of different approaches to the problem. All come with some performance drawbacks, but that shouldn't be a major issue running old 32-bit games on modern 64-bit hardware.

As a matter of fact, the 32-bit x86 instructions work on amd64 CPUs as they always did. So if the CPU architecture doesn't change, this is more of an ABI compatibility thing which can probably be glued around somehow.

There's no such thing as 64-bit DOS games. Hell, I'm pretty sure that there's no such thing as a 32-bit DOS game. Doesn't matter either way since DOSBox is an emulator and emulates a 16-bit environment. A 64-bit build of DOSBox should run 16-bit DOS games just fine.

I am happy for everything going 64bit but I am sure there is always a work around for this stuff. Software emulation has come a long way for playing old games, so that means now I need to prepare myself for what's coming to my damn macbook soon....

As many knowledgeable people are posting the dosbox is the best work around for things now. but maybe wine at some point might update to combat this change.?

This is very bad for Mac gamers as the majority of games are still 32bit. All those games created in the 2000's wouldn't be able to run, hard to imagine it.

This makes literally no sense at all. Why on Earth would Apple disable user installed 32bit programs that aren't using system libraries?

This sounds like something that's speculative or not interpreting the evidence properly. Removing the 32bit libraries has potential upsides in terms of having less installed on the computer and less loaded into memory, but going further than that to outright preventing them from running at all makes no sense at all.
In the case of DOSBox, the actual executable as far as the OS is concerned would be 64-bit even if the software running inside of it was actually 8 or 16-bit.

This whole thing only makes sense if Apple is planning to switch to a 64bit only architecture, but those failed pretty hard last time around and I doubt that Intel is going to try it again.
TBH, a huge chunk of those games will run under virtualization, but it does seem like a truly bizarre decision to make and I assume that there was a misunderstanding here.

32-bit DOS games:
https://www.classicdosgames.com/forum/viewtopic.php?t=1414

Many geeks write new 32-bit codes on DOSBox for convenient.

FAKE NEWS

We all know there is no longer such a thing as a "Mac User". :D

If you want to use multilib, you have to enable it in OS kernel.
Otherwise it will be damn difficult to support 32/64 bit execution at the same time.

If the kernel of macOS still support multilib, 3rd party software could provide 32-bit libraries.
But if Apple remove the feature from their new kernel, you will need emulation/virtualization to run 32-bit codes.

While CPU still support 32-bit native codes, you just can not run it directly/easily in a pure 64-bit-only OS.