The second solution (sending packet_length unencrypted) has a number of desirable properties: it conforms to RFC 5116 so the design should apply to any AEAD algorithm, and it is consistent with the algorithm specification (NIST SP 800-38D). It does require a change to the padding calculations: since the plaintext for encryption excludes the packet_length, the concatenation of the 'padding length', 'payload', and 'random padding' MUST be a multiple of the cipher block size. (This modifies a requirement from Section 6 of RFC 4253.) Since this calculation is algorithm specific anyway, it is hoped this would not be an issue. As you might have guessed, I strongly prefer this solution. However, we are concerned about making such a change without ensuring that the security implications have been thoroughly reviewed.
On first glance, this seems reasonable from a security standpoint; as previously noted, we've seen problems resulting from the length being encrypted, and as you've discovered, treating the encryped length as part of the same plaintext it describes leads to some interesting problems trying to read the encrypted packet off of the TCP stream.
I am concerned about the implications of an encryption algorithm spec changing parts of the base protocol. The protocol is designed such that there is an abstraction between the transport protocol and the individual compression, encryption, integrity, key exchange, and public key algorithms. You propose introducing an encryption algorithm which requires that the transport protocol itself behave differently when that algorithm is in use, not only in not encrypting the length, but in changing the generation of padding on outgoing messages.
I'd rather see an extension to move the length out of the encrypted part of the packet (and makes the required padding changes), which is negotiated separately and can be used with any encryption algorithm. It would then be reasonable to for AEAD encryption algorithms to require support for and use of the new extension.
-- Jeff