The documentation states that the RangeI-N lock (Insert range, null resource lock; used to test ranges before inserting a new key into an index) is compatible with itself (see the compatibility matrix), so even though one transaction has obtained a RangeI-N lock on particular key another transaction can also obtain such a lock.
Further below, it says that
When inserting a value within a transaction, the range the value falls
into does not have to be locked for the duration of the transaction
performing the insert operation. Locking the inserted key value until
the end of the transaction is sufficient to maintain serializability.
For example, given this INSERT statement:
INSERT mytable VALUES ('Dan');
The RangeI-N mode key-range lock is placed on the index entry
corresponding to the name David to test the range. If the lock is
granted, Dan is inserted and an exclusive (X) lock is placed on the
value Dan. The RangeI-N mode key-range lock is necessary only to test
the range and is not held for the duration of the transaction
performing the insert operation. Other transactions can insert or
delete values before or after the inserted value Dan. However, any
transaction attempting to read, insert, or delete the value Dan will
be locked until the inserting transaction either commits or rolls
Quoting another source – Microsoft SQL Server 2008 Internals: Transactions and Concurrency:
For example, the RangeIn-Null lock is acquired when SQL Server
attempts to insert into the range between keys in a session using
Serializable isolation. This type of lock is not often seen because it
is typically very transient. It is held only until the correct
location for insertion is found, and then the lock is converted into
an X lock.
My understanding is that this type of lock is during the process of identifying the range where the newly inserted key should be placed (I'm assuming that's what 'test the range' means). After this happens the lock is released, the new key gets inserted and an X lock is placed on it.
However I do not see why two RangeI-N locks are said to be compatible with each other. If transactions A and B both place a RangeI-N lock on the same key because they both want to insert a new key into the range and transaction A performs the insert first, then the location for key insertion determined by B might be already incorrect because the ranges have changed (A inserted a new value there). Could anyone explain that?