CSV import silently fails when last field in row is a custom field and empty

After a whole lot of detective work, I can reproduce this on two different of our own instances, but have not tried on demo yet.

Import contacts, CSV file, first row contains headers, Individual, Update, dedupe using custom rule that only looks at External Identifier, default separator (,) and default timestamp.

Import a set of data with multiple fields, where the last field in a row maps to a custom field, for contacts which do not yet exist.

For rows where this last field is populated, it will import normally and will exist in the database post import.

For rows where this last field is empty (ie, the row ends on a comma), it will claim to import (it will be reported as part of the successfully modified or updated count on the Import success screen), but in fact the contact will not exist in the database (confirmed both via web interface and sql query).

You can repeat the above experiment with a set of data where the last field is not custom. In those cases, it works whether the last field is empty or populated.

Question 1 is why it's failing in the empty custom field case. Question 2 is how an import of n records (we tested with 1 record and we tested with 10,000 records) can report as successful with many of the contacts not actually created or modified. Some error being trapped somewhere?

Note that when I chose "create and apply new tag" to the import, the tagged count on the import success page was correct. So, it would say, 10000 contacts created or updated, 2 tagged. Only the 2 tagged contacts were actually successfully created.