The 10x concept contains not only the work but the decisions. Not just how to build something, but what to build.
For example, people other than Linus Torvalds can code at the level needed to write and maintain git--as evidenced by the fact that other people do that now; he has handed the project off.
But the creation of git included the conception of git--the many decisions about what he would build, and why it should be that way. Those decisions, coupled with solid coding, have resulted in a massive productivity multiplier for many thousands of people.
So think of somebody who would consider you a 3x. Now the engineer who is 3x relative to you is just about 10x to them.
Now consider the developers with net-zero or net-negative productivity. The 10x rule wildly understates how much more valuable a good engineer is relative to them.
Fabrice Bellard wrote (among many things) a linux emulator in javascript. (http://bellard.org/jslinux/)
I don't know how long it took him to write, but knowing he's also doing other things (http://bellard.org/) including FFMPEG, I don't think he spent his entire career on it.
The OP's opening "I was a 10x engineer for 7 months and then I was a 0x engineer for a year and a half." pretty much sums it up. I think many of us have at least felt to be in both places at different points in our lives. A "10Xer" can be loaded down with dreary (or extremely challenging) tasks that can send their "productivity" off a cliff. Either they burn out, or the nature of their work requires more "breakthroughs". If they are wise enough to refuse always saying yes to their bosses, they can become a wet blanket, which can also seemingly affect their perceived productivity.
(IIRC seeing a study several years back which suggested a 10x increase in cost to address an issue for each step later in the "requirements -> development -> acceptance test -> production" sequence it was identified; even if that's not true in exact numbers, the basic trend of escalating costs is and a developer that, on a team, leads to the team doing substantially better at identifying problems up front might get the code they directly write through the process from requirements complete to ready to test at the same speed as other developers and still be a 10x developer.)