Ed25519 PKCS8 private key example from IETF draft seems malformed
That example private key is not encoded with PKCS#8, but with the format described in RFC 5958, which is supposed to replace PKCS#8 (at least, in IETF parlance, RFC 5958 "obsoletes" RFC 5208, which is a copy of PKCS#8 v1.2). The ASN.1 type if called OneAsymmetricKey:

 OneAsymmetricKey ::= SEQUENCE {
   version                   Version,
   privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
   privateKey                PrivateKey,
   attributes            [0] Attributes OPTIONAL,
   ...,
   [[2: publicKey        [1] PublicKey OPTIONAL ]],
   ...
 } 


The structure is similar to that of PrivateKeyInfo in PKCS#8, but with the extra publicKey field (optional) at the end. Also note that the version field, which is an INTEGER, has value 0 for PKCS#8, but value 1 for OneAsymmetricKey; this is meant to allow some level of backward compatibility, in the sense that a decoder for OneSymmetricKey can accept an encoded PrivateKeyInfo, and will use the version field to apply the proper semantics (i.e. to decode the contents of the private key blob).

I must say that I have, so far, never encountered a OneSymmetricKey structure in the wild. The openssl command-line tool encodes keys in PKCS#8, and applications tend to expect that. RFC 5958 has status "proposed standard", but sometimes you cannot enforce acceptance.