Yes. the lock resource is a hash, two different rows may get the same lock-resource value, and therefore with some bad luck, you can get blocking or even deadlocks with unrelated rows, because they have the same lock hash.
However, it is not correct that the hash is computed from nvarchar values only. The lock hash is computed from the key values. Look at this:
CREATE TABLE nisse (Col1 nvarchar(20) NOT NULL,
Col2 nvarchar(20) NOT NULL,
Col3 date NOT NULL,
PRIMARY KEY(Col1, Col2, Col3))
go
INSERT nisse (Col1, Col2, Col3)
VALUES('AB123.12', '1', '2023-02-12'),
('AB123.1', '21', '2023-02-12'),
('AB123.1', '21', '2023-12-12')
go
SELECT *, %%LOCKRES%%
FROM nisse
go
DROP TABLE nisse
The rows with the same date indeed has the same lock resource because of the accident with the strings. But the row with a different date also has a different lock resource.
It is difficult to give advice how you should deal with your deadlocks, since I don't know about your application. But I as said, I think it takes a bit of bad luck to end up in this situation, and some trickery may be needed to work around it.