That logic can be done in one single update (which doesn't require any particular locking strategies or isolation levels):
DECLARE @nextMergeID INT ;
DECLARE @customerID INT;
DECLARE @mergeDate DATETIME;
DECLARE @reset BIT;
SET @nextMergeID = merge_id
, picked = 1
, lub = 'v2'
WHERE merge_id = (
select top 1 merge_id
where picked = 0
order by merge_date asc
testing your method against the above single update, I created a merge_standard_queue table:
drop table dbo.merge_Standard_Queue
create table dbo.merge_standard_queue
( merge_id int identity(1,1) not null primary key
, merge_date date not null
, picked bit not null
, lub varchar(10) null
INSERT INTO dbo.merge_Standard_Queue (picked, merge_Date)
, DateAdd(day,t.Number, '2010-01-01')
from tally t
(my tally table has 32,767 rows, so that's a reasonable size to test against).
Then I opened two separate windows in SSMS, one with your script (amended to set lub to 'v1'), and one with the single update version above, and ran them both 255 times concurrently (with a GO 255).
The results were interesting...
Both reported "Batch execution completed 255 times.", but your script never updated 255 rows, whereas the single update statement always updated 255 rows every time.
select lub, count(*) from dbo.merge_standard_Queue group by lub
returned (as an example, the actual number of updated rows varied between iterations)
lub (No column name)