Deadlock on insert for a table with an insert trigger that updates column in same triggered table
I have to say that I don't quite agree with some of the comments that state that what you're seeing is necessarily a framework problem.  The Linq to SQL framework most certainly does allow you to specify a stored procedure as the means of input for rows.

That being said, I'd highly recommend you use that mechanism instead of a trigger if at all possible.  You'll be able to add your locking hints inside the stored procedure and your inserts will work fine. 

Your spec, however seems highly suspicious to me, and IMO the problems you seem to be running into right now are good counterexamples as to why one might not want to pursue a design such as this.  So my (purely rhetorical) question is for the designer.  What is that problematic sequential number supposed to represent?  If it's a sequence in time, then why not just use a time and use the window functions to order the rows in something like a view instead (you can point Linq to SQL to views as well)?  Is the intent to have some sort of gapless sequential number?  Are you signed on to all of the complexity and locking you're going to have to deal with just to maintain that number?  

Unfortunately, I think there is no real answer -- no magic combination of hints which will work across your frameworks and design -- which will solve your problem.  IMO my answer is take a step back and look critically at your design.