You know nothing about how deep or how shallow my CS background is.
Real World crypto is different from other areas of programming in that:
If you do something dumb, the bug is not obvious. The bug is silent, until someone exploits it and hacks your system.
For this reason, it makes sense to use standard, well established primitives (like dtls) that the community has adopted and that has been hardened through attacks, rather than trust a random protocol a anonymous user proposes online in a paragraph of ambiguous English, without providing any formal proofs of security.
You still have not answered the original question of whether crypto_box supports dtls, which I am now going to assume it to be: if it did, you don't have sample code.
DTLS is a specific protocol that happens to support that kind of out-of-order messages, and not a term used for all protocols that support out-of-order messages. The crypto_box primitive also supports out-of-order messages, but it is different from DTLS.
crypto_box has support for encrypting a single packet
or
there is another well known protocol, FooBar, different from DTLS, for allowing out-of-order decryption, and crypto_box supports FooBar ?
====
If you are asserting #2, my followup would be: what is FooBar ?
If you are asserting #1; I don't think that is useful -- because there are situations where you have a primitive that can encrypt a single packet correctly, but if we incorrectly use it to encrypt many packets with the same key, we leak information. [Dumb example: xor with a one-time pad. Two packets = we leak the diff of the unencrypted packets.]
Well, I'm sorta saying #2, but only to the extend in which crypto_box itself counts as that protocol. Crypto_box is designed to let you encrypt many packets, and doing so is safe as long as you don't reuse the same nonce for two packets. There is no requirement that the nonces are in increasing order or anything like that, which is what allows them to be decrypted out of order. The nonce is not secret and can be sent in plain-text in the UDP packet together with the encrypted payload.
The crypto_box function is designed to meet the standard notions of privacy and third-party unforgeability for a public-key authenticated-encryption scheme using nonces. For formal definitions see, e.g., Jee Hea An, "Authenticated encryption in the public-key setting: security notions and analyses," Authenticated Encryption in the Public-Key Setting: Security Notions and Analyses.
Distinct messages between the same {sender, receiver} set are required to have distinct nonces. For example, the lexicographically smaller public key can use nonce 1 for its first message to the other key, nonce 3 for its second message, nonce 5 for its third message, etc., while the lexicographically larger public key uses nonce 2 for its first message to the other key, nonce 4 for its second message, nonce 6 for its third message, etc. Nonces are long enough that randomly generated nonces have negligible risk of collision.
There is no harm in having the same nonce for different messages if the {sender, receiver} sets are different. This is true even if the sets overlap. For example, a sender can use the same nonce for two different messages if the messages are sent to two different public keys.
The crypto_box function is not meant to provide non-repudiation. On the contrary: the crypto_box function guarantees repudiability. A receiver can freely modify a boxed message, and therefore cannot convince third parties that this particular message came from the sender. The sender and receiver are nevertheless protected against forgeries by other parties. In the terminology of https://groups.google.com/group/sci.crypt/msg/ec5c18b23b11d82c, crypto_box uses "public-key authenticators" rather than "public-key signatures."