Inferno, which sdrapkin cited as an example of crypto done right, offers this API:
public static byte[] Encrypt(byte[] masterKey, ArraySegment<byte> plaintext, ArraySegment<byte>? salt = null)
The docs suggest:
The "salt" parameter can include Additional Data (AD) or its hash - which will also be authenticated.
This is, in my opinion, not okay as a high-level easy-to-use primitive, as it leaks information if you don't properly use the salt.
EDIT: I read the source (https://github.com/sdrapkin/SecurityDriven.Inferno/blob/mast...), and Inferno's primitive is randomized. This avoids the info leak, but it's likely to be a decent amount slower as a result, and the primitive needs a good RNG. As a result, it might be vulnerable to failure if the application uses fork(), it's awkward to implement on some embedded platforms, etc.
The point of nonce-misuse-resistant encryption is to reduce the damage from nonce reuse, not to give you an excuse to ignore nonces entirely for encryption of arbitrary data.
"vulnerable to failure if the application uses fork()" - I strongly suspect that your comfort-zone is c/c++/Linux/*nix, and not .NET framework and Windows. You failure scenario does not apply to Inferno.
If CSRNG is "awkward to implement on some embedded platforms" then it is a platform problem, not Inferno's. Inferno is designed to take full advantage of plentiful (ie. high-quality/cheap/fast) cryptographically-strong randomness available to .NET framework on Windows.
You question Inferno's speed - performance is in the eye of the benchmark beholder - but I doubt you have run any (ie. this is likely FUD). Based on the benchmarks I've run, Inferno is very fast.
Inferno does not ignore nonces - it force-randomizes them internally to the maximum extent (320 bits of entropy). This creates a nonce-misuse-resitant design which eliminates user-supplied nonces, and does not break even under a faulty CSRNG producing a lot less entropy than it should.