That's right - there isn't much to discuss here.
Fix will be coming soon.

Should fasm allow negative values for register operands?

It is documented the same way for btc, btr, bts, shr, shl, shld and shrd, it takes the modulo bits_of_dest of the immediate.

As for legitimate uses of this could be "counting from the left" immediate, so if you always want to take the bit just before the sign bit, you use -2 and then you don't care of the dest register your macro will receive because the immediate will always pick the correct.

For the others you can think of them as "keep the last/first n bits" again with independence of the destination size.

I've just woke up so I hope I didn't say complete nonsense

Since imm8 there is working as some sort of bit set, I think it is right to accept negative values.

The only problem I see however, is that since fasm can't distinguish between 64-bit negatives and real negatives, there is some kind of odd thing in that fasm accepts all ones or all zeros but not any other combination in the upper 48-bits. I think that the imm8 in pshufd xmm0, xmm1, $FFFF'FFFF'FFFF'FFxx may have to be considered out of range because the Fs are not acting as selectors of any muxer. On the other hand, in $0000'0000'0000'00xx the 0s are not handling any muxer neither but it is a correct representation of the $xx number and for that reason the all Fs version may be a correct representation of a negative imm8 as well...

I presume you mean 56-bits?

For the BT case I think that negatives are okay. But for the PSHUFD (and similar) there is no notion of the imm8 having a sign. Indeed is it not even an integer value, it is a bitmap selection. To use negative numbers is a strange way to define a bitmap constant.