Andrew Mayo suggested shooting the person (ir)responsible
for the bizarre sublw instruction and
the backwards behaviour of the C flag

Personally I think this is far too quick.
Even if they were shot somewhere not swiftly fatal.
Some supernatural punishment would be appropriate.
Prometheus had his liver pecked out by a giant eagle
day after day (it grew back) for stealing fire from
the gods. Perhaps in an afterlife, the chip designers
will suffer the frustration of every programmer who had
to use their chips.

I can think of many moans about PICs.
Had the original architects ever seen other microprocessors?
This might explain why they have their own unique terms, i.e.
"file" where almost everybody else uses "register"
"w file" ... "accumulator"
"literal" ... "constant"

I'd like to see bit-operators that actually work on just the one bit!
I know the Read/Modify/Write cycle is fine on internal registers,
but it requires careful thought to avoid problems on I/O ports.
I know you can work-around this by byte operations.
I'd accept this if my program spent most of its time processing,
but the raison d'etre for most PICs is to twiddle I/O bits. A lot.
A pretty fundamental architectural screw-up I think.

I'd also like some proving code.
By this I mean that if a chip maker says it can drive the I2C bus,
lets see the code they used to prove that it works.
Don't say "read the application notes".
I have. They don't demonstrate the full I2C bus specification.
Either they have or have not got proving code.
If they have, why not publish it instead of these half-baked
application notes? It would sure be a help to PIC programmers.
If they have not, then they're not entitled to say the chip works
to spec.

I'd like to see instruction sets start to look a bit more like
        r[a]  = r[b]            r[a]  = constant
        r[a] += r[b]            r[a] += constant
        r[a] -= r[b]            r[a] -= constant
        r[a] |= r[b]            r[a] |= constant
        r[a] &= r[b]            r[a] &= constant
        r[a] ^= r[b]            r[a] ^= constant
        bit[a] = 1              bit[a] = 0
        bit[a] = bit[b]         bit[a] = !bit[b]
The bit copying instructions would be nice (copy true or inverted).
PICs do a lot of bit-level operations!

I wish they'd get rid of all the existing complaints mentioned
by others in this thread.

I wish that all PIC instruction sets had a register specification field
that was always wide enough to uniquely address any one of all
the registers it has. So nobody has the huge headache of
data page management.

I wish that all PIC instruction sets had a address specification field
that was always wide enough to uniquely address any one of all
the code locations it has. So nobody has the huge headache of
code page management.

I wish they had on-chip serially-programmed Flash code memory

I wish they had in-site programmability.
Not as easy as you think. You can't easily power the PIC in isolation,
and even if you could, how will the I/O pins behave? You don't want
them doing anything undesirable through the items they're
connected to. I've seen some published articles about how to
implement in-site programmability. Typically by having controlled
buffers surrounding the I/O pins. But of course this is prohibitive in
cost-sensitive apps requiring PICs.
If you have the ability to set the I/O pins during programming,
you're heading toward JTAG testing!

I wish they had verifiable code.
As it is, code-paging makes things such that you can't even
disassemble jumps and branches to unique locations!