not sure.
https://wdc65xx.com/ says
> WDC has licensed our 65xx technology to a number of companies over our long history including MOS Tech, Rockwell, GTE, CMD and many others.
rockwell, mos technologies, and cmd don't exist since 02001, gte since 02000. i suspect this page hasn't been updated in quite a while, maybe since last millennium, and possibly if they were ever making hundreds of millions per year they aren't now. https://wdc65xx.com/where-to-buy has been updated and has their current stock numbers, which total under 31000 for all their microcontrollers and microprocessors, which would be 8 hours of stock if they were making a hundred million per year. a hundred thousand seems more plausible
mouser has another 4000 or so in stock, again summing all the different skus. by comparison they have 38000 attiny13a-ssur chips https://ar.mouser.com/ProductDetail/Microchip-Technology/ATT..., 22000 atsamd20e16b-mut chips https://ar.mouser.com/ProductDetail/Microchip-Technology/ATS..., 28000 pic18f46k42-i/pt chips https://ar.mouser.com/ProductDetail/Microchip-Technology/PIC..., almost 63000 stm32f030f4p6tr chips https://ar.mouser.com/ProductDetail/STMicroelectronics/STM32...
digi-key doesn't actually have the w65c02sxb, which is an eval board. that's a 'marketplace product' meaning that digi-key just sends your order to another seller, in this case wdc. they do have 5 units of the w65c02s and 17 units of the neo6502, which are eval boards from olimex. no bare chips
as for the furby, it used the spc81a, a 6502 clone that lacks the y register. more importantly, though, the spc81a is evidently mask-programmed and lacks any apparent way to get it to use external memory. so it's probably useless as a microcontroller to scavenge. the same can be said of keyboard and mouse controllers: although conceivably they might use a 6502 instruction set, they aren't of any use if you can't reprogram them
i can't find any information on tiger electronics handheld games hardware, but given that they designed the furby, i suspect the story will be the same there: game in rom, not enough pins for a memory bus (though you can use the spc81a's i/o ports to control an external bit-serial memory; the datasheet suggests an spi ram)
as for traffic lights, the last traffic light controller i saw open was electromechanical, no visible electronics beyond diodes, so i don't think you're going to be salvaging very many microcontrollers from traffic light controllers; there are too few per population and their replacement lifetime is too long
a vision i think is a lot more appealing is self-sufficient microcontrollers. cp/m was perfectly capable of self-hosting, although dec machines gave it its initial bootstrap. a 4-megahertz z80 was perfectly adequate for assembling the bios, bdos, and command processor, despite having only something like 0.5 8-bit mips and 0.05 dhrystone mips (https://netlib.org/performance/html/dhrystone.data.col0.html), with 64 kibibytes of ram or even less, and only a 90-kibibyte floppy or two for mass storage. bds c provided a reasonable facsimile of a c compiler that would run on cp/m
contrast that to things like the atsamd20e16b microcontroller i mentioned above: a 32-bit cortex-m0+ running at 48 megahertz and about 60 dhrystone mips, 64 kibibytes of in-application-programmable nor flash, and 8 kibibytes of sram, whose spi interface can control a microsd card with gigabytes or even a terabyte of nonvolatile memory, accessible not at kilobytes per second but megabytes per second, with access latencies measured not in seconds but microseconds. it supposedly uses 50 microamps per megahertz; at 1.8 volts that would be 90 picojoules per clock cycle and so about 100 picojoules per instruction. running on a milliwatt it would still provide you 10 million instructions per second. mouser will sell them to you for two bucks fifty. or lcsc will sell you a cypress cy8c4045fni-ds400t for 1.5¢: https://www.lcsc.com/product-detail/Microcontrollers-MCU-MPU... which is also a 48-megahertz 32-bit arm but with a tiny amount of ram
these seem like the kind of thing you'd want to be using if you're concerned about sustaining the ability to program microcontrollers in the face of societal collapse
with respect to duskos, i've been reading through their documentation and it doesn't seem like an unreasonable approach. possibly the wrong approach but it does seem like they're considering engineering tradeoffs rather than cosplaying steve wozniak