Hello,
thank you for the links.
Here are my comments/answers.


This BIP describes a key derivation scheme. This is certainly a better way than storing individual secret keys. However, one must still maintain a database associating the key derivation data with the keys.  My proposal does not need a key derivation scheme, because only one secret key is needed.




to item 1:
This proposal has one drawback, as the thread starter already noticed:
(Please note that proposed solution to this issue by user "thanke" in the same thread does not work. An attacker can simply calculate E*(txin^(-1)) for any transcation and compare the public keys)
Contrary to this, my solution does not have this drawback.     

to item 2:
This is essentially  the same as item 1

to item 3:
Let's compare your proposal(4) with mine:

system complexity:
Your proposal needs an additional private/public key pair for encryption.

mathematical complexity:
Lets assume you're using Elgamal encryption. For simplicity, lets count only ECC operations.
For sending you have to perform one scalar multiplication to get the new point k*QA and than do an Elgamal Encryption, which costs two scalar multiplications plus one addition:
My proposal needs only two scalar multiplications for the blinding of the public key
For checking the transactions you have to perform an Elgamal decrytion to get the anonymity key (1 scalar mult and one add) and than do a scalar multiplication with this key. 
My proposal need only one scalar multiplication. One only has to check if P' = f*G', where f is the fixed secret key. 

In summary:
              yours                 mine
SEND       3 mult, 1 add      2 mult
CHECK     2 mult, 1 add      1 mult

to item 4:
I cannot see how this proposal is related with mine.