Yes, a transaction that was never committed or rolled back can leave an "orphaned" transaction--with any rows that it modified left in an indeterminate state in the database.  Any other connection attempting to modify the same row(s) will get a concurrency error because the state of the prior transaction can't be determined.  In a NonExclusive environment there's no way for it to know whether the other connection is still open or has left it orphaned.

If the connection is properly closed then a pending transaction should get automatically rolled back, so--other than when it is actually still pending in the open connection--the main way these "orphaned" transactions can occur is if execution is killed without executing the usual .NET cleanup code to dispose the connection and transaction objects.  This can typically happen by stopping in the debugger, by hard-killing the process, or by loss of power to the machine.  It should be rare for this to happen in production--although if your code does not ensure proper cleanup/disposal of open connections upon exit (or exits in an unusual way that bypasses it) it may also occur more easily even in normal use.

To remove the orphaned transactions the database needs to be Packed.  This requires an Exclusive connection, so there can't be any transactions still pending and any it encounters can be assumed to be orphans and rolled back since they were never actually committed.

It occurs to me that any Exclusive connection could similarly assume that any unknown transaction is an orphan and should be rolled back, even without a pack.  It doesn't currently support doing this, but that's something we should look into.