Delayed tag checks in AES-GCM for streaming data There is currently a GitHub discussion on .NET not supporting AES-GCM for any streaming data since releasing decrypted data prior to tag checks somehow reveals the plaintext or the AES key (or some such undocumented catastrophic failure). A lot of chatter between two choices:

1. Allowing AES-GCM for streaming data

Release data as it is decrypted and alert caller if / when tag check fails. Most popular AEAD constructs (e.g. AES-CBC-HMACSHA256) are encryption and authentication as two separate pipelines. So one can at least momentarily downgrade to privacy-only mode during decryption (i.e. AES-GCM => AES-CTR mode) but upgrade back to privacy and authentication mode after the GHASH tag checks out. The caller is responsible for alerting users or buffering data if situation demands. 

2. Permanently disallow AES-GCM for all streaming data

This eliminates AEAD (or specifically AES-GCM) from streaming and limits them to regular privacy-only mode permanently. Or forces users to bolt-on authentication themselves, which revisits the original problem. Or worse, users consider streaming as a dead-end case and skip any encryption at all.

Question: Assuming everything else is ok (fresh keys, unique iv, long tags, under GCM limit etC), is allowing streaming (#1) with AES-GCM ok? If not, what's the catastrophic failure and what choice other than AEAD does streaming have? If the case for AES-GCM differs significantly from generalized AEAD, please address that too.

The Windows 'kernel' crypto layer (bcrypt), OpenSSL, Bouncy Castle (C#) and Java Cryptography Architecture all allow for streaming/continuation.

Also, the scope of this is the crypto API itself, NOT a high level protocol.
You can have AES-GCM and streaming at the same time.  But:

Do not operate on unauthenticated data!

Treat unauthenticated data like nuclear waste.

The fact that the AES-CTR out of which AES-GCM is built technically can provide access to data before the authentication tag is verified is a red herring.  Allowing access to the data before verifying the tag, and requiring a separate API call to verify the tag, is a loaded semiautomatic foot-pointed gun.  Don't do it!

Do not allow arbitrarily long messages before you verify authentication tags!

Arbitrarily long messages will tempt you to act on the content of the message before you can verify the authentication tags.

Resist the temptation!  Al you have to do is break long messages into chunks of bounded size so that you aren't even tempted to do this.  You can even use a chunk sequence number for the AES-GCM nonce, or you can use a scheme like miscreant that handles chunking for you.

Fogeries are bad news!  Every program is an interpreter for a programming language that is its input—sometimes that language is Turing-complete, or even if not you may still enable an adversary to control a weird machine you never even thought existed in ways you never imagined.  The cryptography lets you ensure that only the peer you're trying to have a conversation with gets to program your program, and not anyone else on the internet.

If the governor of Arkansas acted on a series of forged execution orders, and only afterward checked all the judges' signatures on them, people would be even more upset than they already are about the lethal carceral state.  Don't let your program be that governor!

See an earlier answer about xsalsa20poly1305 for elaboration on the performance and denial-of-service implications of bounded-size chunks in a cryptosystem of the same type as AES-GCM.