QueryFirst<> Ignores SQL Error

We had a bug in a stored proc that left a transaction open. Completely understand this is a bug in non-Dapper code however I feel Dappers handling of SQL Errors is flawed, inconsistent with other Dapper methods and dangerous.

Take a simple SP that replicates our problem:
BEGIN TRANSACTION
INSERT INTO....
SELECT .....

When you call this SP from Management Studio you get the error: "Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 0, current count = 1."

When you call this SP using .net native SqlCommand you get an SqlException with the same error.
When you call this SP using .net native SqlCommand ExecuteReader() you don't get this exception unless you iterate all the results with NextResult() at which point you get an SqlException with the same error.
When you call this SP using Dapper .Execute you get a SqlException with the same error.
When you call this SP using Dapper .QueryFirst you get a result, no exception.

Regardless of the scenario it feels wrong to me that QueryFirst would ignore an error returned from SQL server just because there is a successful result included as well. This is any error not just my transaction example. Any business logic using RAISERROR/query mistake goes un-noticed and could be within a .net TransactionScope which now gets committed.

This does appear standard behaviour in .net for ExecuteReader(), but can be solved by always calling NextResult() until there are no more results. This would feel much safer to me; i'd rather always know if there is a bug rather wait for some obscure symptom.

Start by reproducing the stored procedure through Dapper QueryFirst, Dapper Execute, and native SqlCommand ExecuteReader, including full result iteration. Trace how QueryFirst handles results and SQL errors; done means its behavior is consistent with the other described paths and the mismatched transaction error is not silently ignored.