Dapper MultiMapping: Inconsistency when the splitOn column is NULL

This is using Dapper 2.0.90 from Nuget and tested with both System.Data.SqlClient and Microsoft.Data.SqlClient.

Description:
When executing a MultiMapping query in the form of Query<T1, T2, TRes> and the splitOn column is NULL in the SQL result, Dapper behaves differently depending on whether the T2 type has a column with the name specified as splitOn parameter.

If T2 has a property with the name as specified in splitOn, the map-function receives null for the second parameter.
If T2 doesn't have a property with the name as specified in splitOn, the map-function receives an instantiated T2 object for the second parameter.

This is inconsistent behavior and breaks the usage of "surrogate splitters". Since this command is frequently used for left outer joins, it's no longer easily possible to check if the left outer join had matching row(s) or not - the second parameter passed to the mapper function is never null with surrogate splitters.

Example:

class T1 { public int Id { get; set; } }
class T2 { public string Name { get; set; } }

conn.Query<T1, T2, bool>("SELECT 1 as Id, NULL as Name", (t1, t2) => t2 is null, splitOn: "Name").First(); //returns true
conn.Query<T1, T2, bool>("SELECT 1 as Id, NULL as Splitter, NULL As Name", (t1, t2) => t2 is null, splitOn: "Splitter").First(); //returns false

Expected result: both queries should return false.
Actual result: the first returns true, the second false.

No repository files or tests are named. Start by reproducing the two Query<T1, T2, TRes> examples with the SQL client providers mentioned, then trace the multi-mapping path for NULL splitOn columns. Done means both queries pass the expected null-check behavior, with a regression test covering named and surrogate splitters.