Do things e.g. pfSense support that already? "Hold" an outgoing connection from the moment the SYN is observed, notify whatever client, and only allow if the user clicks?
Not that I am aware of.
This is a desktop centric workflow where the user can react live to an application that is sending traffic.
Your typical network firewall will apply a set of static rules and the decision to log/reject/drop is done ASAP. Waiting for user input is impossible.
Some systems can show logs of recent blocked traffic, and allow an admin to quickly generate an exception/allow rule for blocked traffic but that's pretty much it.
Alternatively, you could possibly use a divert(4) socket — coupled with a targeted firewall rule — to divert only the initial SYN packet, and if the connection is to be permitted, re-inject it and allow connection to proceed normally.
OpenBSD supports using divert(4) sockets with pf; unfortunately, FreeBSD divert(4) sockets only work with the older ipfw firewall.
that said, the description could be covered by something like captive portal.
What makes LittleSnitch/Lulu/similar nice is they listen for "all" outgoing traffic types TCP/UDP/ICMP/etc, and show UI immediately, including for non-browser apps, e.g. games, VoIP, P2P apps, whatever -- it tends to be covered. Unless I'm mistaken I don't believe a captive portal can be triggered when "just any" process originates traffic.
That's the strength of LittleSnitch/similar, but the major weakness with host-level filtering they rely on, is you're 100% at the mercy of Apple's networking stack, and this Sonoma issue isn't the first time Apple moved the goalposts. Not too long ago Apple exempted their own services from whatever LittleSnitch hooks [1] and it could of course happen again with any macOS update.
In my view this is precisely why a separate box is appealing. Ideally it'd have as tight of a UI as the incumbent apps, including the same metadata (process name + app icon, protocol, port #, most recent previous attempt, etc).