Do not try to write --keyspace yourself

[epixoip]

According to the FAQ 129988 is correct as the rules are never taken into account for -a 0, which seems strange.
The calculation of 'hashcat legacy' seems to make more sense for -a 0 as the "number of words in wordlist multiplied by number of rules in rule file"

I can't really explain it any better than I already did in the thread you linked to. I guess I can try to expand upon it.

In order to accelerate fast hashes, we have to actually give the GPU some work to do. Generating the passwords on the host and sending them to the device(s) for hashing isn't anywhere near enough work, see for yourself by using e.g. MD5 + stdin. We give the GPU the additional work it needs to gain acceleration by generating password candidates directly on the device(s).

But in order to do that, we have to tell the devices which candidates to generate, which means we have to keep track of some of the candidates on the host. This means we end up with two loops: a loop that runs on the host (the "base loop"), and a loop that runs on the device (the "mod(ifier) loop.") If you are at all familiar with the original oclHashcat, then the concept of "left" and "right" should sound extremely familiar. In the original oclHashcat you had to specify these loops manually, but that changed like 7 years ago (holy shit has it really been that long??)

When we're distributing work between multiple compute nodes, we need a way to control the base loop. This is where --keyspace, -s, and -l come into play. --keyspace reports the size of the base loop that executes on the host so that we know how to divide up the work, and we use -s and -l to control the start/stop positions of the base loop.

With a straight attack with rules (-a 0 -r), Hashcat has an on-device rule engine, meaning the rules are executed directly on the GPU. This means that the base loop is simply the words in the wordlist, and our mod loop is our rules file. This is why when you use --keyspace with a straight attack with rules, it reports the keyspace as the number of usable words in the wordlist.

The calculation of 'hashcat legacy' seems to make more sense for -a 0 as the "number of words in wordlist multiplied by number of rules in rule file." Maybe atom could clarify why this changed?

It didn't change. hashcat-legacy was CPU-only, and thus its architecture wasn't structured for GPU cracking. Candidates were generated and hashed directly in one loop. This architecture does not work for GPU cracking, however. JTR is a prime example of this.