Forward-secure static-ephemeral ECDH key agreement protocol The question is whether the following simple key agreement protocol design has good security properties, and how it can or should be improved.

Assumptions


Alice is a persistent entity with a static and well-known public key.
Bob is a transient anonymous party who would like to exchange some private information with Alice over the public Internet in a session of short duration (less than an hour), in a way that is forward-secure (has the forward secrecy or PFS property).
Bob has a good copy of Alice's static public key.
Bob must authenticate Alice, but Alice need not authenticate Bob.
All key and ECDH operations use Curve25519 or another SafeCurve.
The final shared secret that is the outcome of the protocol will be used to secure the data transfer between Alice and Bob (which takes place with a separate protocol) by serving as the key to an Encrypt-then-MAC authenticated encryption (AE) procedure (for example, XSalsa20/Poly1305) that also requires a unique-per-(key, message) nonce as input.
The transport protocol is message-based (not TCP), and protocols such as TLS and DTLS are not applicable.


It is well known that using mature and battle-tested key exchange protocols is usually the right answer, so pointing this out is unnecessary.  Useful answers will provide specifics as to any problems with this protocol and, especially, how they can be corrected.

Protocol


Bob generates an ephemeral (private, public) keypair (b, B).
Bob computes the DH shared secret X using his private key and Alice's static public key A, and then K(X), the result of applying an appropriate key derivation function (KDF) to the combination of A, B, and X.
Bob initiates communication with Alice by sending her a (cleartext) message that contains some fixed protocol information such as a magic number and version, and a copy of Bob's public key B.
Alice receives the message and computes the DH shared secret X using her static private key a and the public key B that Bob sent.  She then computes K(X) as Bob did.
Alice generates an ephemeral (private, public) keypair (e, E).
Alice generates a unique nonce N0 and the ciphertext C that results from applying AE with nonce N0 and key K(X) to her ephemeral public key E.  She then sends N0 and C to Bob.
Bob receives the message and authenticates/decrypts it with AE using the nonce N0 sent in the message and key K(X).
Both Alice and Bob compute the DH shared secret Y using their ephemeral keys (e, E) and (b, B), and then K(Y), the result of applying the KDF to the combination of E, K(X), and Y.  The values X, K(X), and Y are discarded.
At this point the protocol is complete, and data transfer is carried out separately using AE with key K(Y) and a unique nonce sent in the clear with each message.  When the session is finished, the ephemeral keys (b, B), (e, E), and K(Y) are discarded.
The protocol seems secure. Some comments below.


  
  Bob computes the DH shared secret X using his private key and Alice's static public key, and then K(X), the result of applying an appropriate key derivation function (KDF) to the combination of A, B, and X.
  


The DH secret X already depends on both key-pairs. Including the public keys in key derivation does not seem to add security.

(Also, in practice Bob should calculate X after sending the ephemeral key to Alice, while waiting for reply, so it is not part of the critical path.)


  
  Both Alice and Bob compute the DH shared secret Y using their ephemeral keys (e, E) and (b, B), and K(Y), the result of applying the KDF to the combination of E, K(X), and Y.  The values X, K(X), and Y are discarded.
  


Again, the inclusion of anything but Y in key derivation seems unnecessary.


  
  [...] When the session is finished, the ephemeral keys (b, B), (e, E), and K(Y) are discarded.
  


The ephemeral key-pairs (b, B) and (e, E) can be discarded already  in step 8 after Y is calculated. Unless you use them for something else, in which case you need to look at how that might interact with the protocol.