If someone remade the 6502 on new processes, how fast?

If someone were to remake the 6502 on new manufacturing processes, how fast would it run? Keep in mind I'm negating the effects of RAM speed here, let's just say it's all embedded SRAM. And that the 6502 has no additional pipelining or out-of-order execution or branch prediction or anything like that.

I would like to see how a 6502-style CPU with the annoying quirks taken out, like not being able to do math with X and Y, and having to clear carry before adding.

I don't even know if anyone has done bare NMOS designs smaller than 1.5µm ... but assuming that we can, and that it works ok ...
This slide deck implies that we "should" be able to get a clock size increase almost proportional to the feature size change.

AIUI, the original 6502 was made at an 8µm process and could run at ≈2MHz, so scaling it down to an 80nm process (not too old, not too new) should be able to trivially get to 200MHz. (Which doesn't sound very impressive given that people can synthesize softcores in FPGAs that run that fast)

I always felt that one thing that would have helped with x and y not being able to do math is if there was an instruction that didn't overwrite the contents of something like how the accumulator is in "tay", but if there was something like "say" that would actually swap the values in a with the ones in y. The carry in adding and subtracting is still an issue, but I don't see how it would be that hard to just add "add" or "sub". This is kind of random, but on the 65816, I've noticed that all the instructions fit in 8 bits, and I was wondering, is there some kind of big penalty if you increased it, and if you do increase it, could you just add one or two bit, or would it make more sense to increase it by a byte?

If you want a 6502-style instruction set with more orthogonal registers, consider Thumb.

I believe it would work at a few hundreds of MHz. The Western Design Center actually still design such chips (except they are 65C02) as for today, they are used in part of other designs (god knowns where).

The rationale is that the bottleneck is SRAM access. It would turn down to how fast can you make SRAM that can be acceded with 6502-style bus in a quantity of 64K (or less) in a chip. Also, a processor with only RAM is as useful as a shoe box, it needs at least some memory mapper I/O in order to have a visible effect to the outside world.

The HuC6280 CPU (in the PC-Engine/Turbografx-16 and a few Data East arcade games) has these very instructions: SAX, SAY, and SXY. It also has bit testing (+branching), block transfer, etc. instructions.

You could make the data bus wider, but if most of the instructions/data aren't using the extra bits, then those bits can add up to a lot of unused memory. An 8-bit alternative might be to use an instruction that changes to another mode, where all the opcodes could have a different meaning. If the most common ones could exist in both sets, maybe you wouldn't have to switch as often. Going to 16-bit wide seems like it would at least have the benefit of speeding up some operations, like reading a 16-bit operand in one cycle. Or reading an opcode + 8-bit operand in one cycle.

I think that would be too confusing for the programmer. I would just have certain instructions use a second byte. The 65816 has a reserved opcode for extention.