Hi Pieter,
Let me put change (1) into my own words. We are already computing affine coordinates since we store public keys as the affine x-coordinate. It is faster to compute is_even(y) than is_quadratic_residue(y) so we get a speed up here during keypair generation. In the verification algorithm, we do the following for the public key x_only => affine + negate if not is_even(y) => jacobian. The minor slowdown in verification comes from the extra evenness check and possible negation which we didn't have to be done in the previous version. This seems like a reasonable change if it makes things easier for existing code bases and infrastructure.
With change (2), I feel like including this auxiliary random data is overkill for the spec. For me, the main point of the spec is the verification algorithm which actually affects consensus. Providing a note that non-deterministic signatures are preferable in many cases and here's exactly how you should do that (hash then xor with private key) is valuable. In the end, people will want several variations of the signing algorithm anyway (e.g. pass in public key with secret key) so I think specifying the most minimal way to produce a signature securely is the most useful thing for this document.
I feel similarly about hashing the public key to get the nonce. A note in the alternative signing section that "if you pass the public key into `sign` along with the secret key then you should do hash(bytes(d) || bytes(P) || m)" would suffice for me.
Despite only being included in the alternative signing section, I it would be nice to have a few of test vectors for these alternative methods anyway. Perhaps they even deserve their own BIP?
Cheers,
LL