Since you're only checking for an hour range, you can use BETWEEN.  It's just as accurate and easier to code and read.

To make changes easier -- and the code somewhat clearer to read -- I usually use this method for that:

WHERE DATEPART(HOUR, LOADDATE) BETWEEN 9 AND 17

After specifically a space, as you stated, that method's likely the best way.  But if you need to consider chars other than a space before the letter, then you'll need...

If you're working with SQL Server, look for SQL Server internals material.  One prominent author worth checking out there is Kalen Delaney and Paul White.  Lookup her/his stuff online  (since...

INSERT INTO [dbo].[TestNames2] ( [MBR_NM] ) VALUES
    ('von Richthofen, Manfred')

SELECT
    MBR_NM,
    RTRIM(LEFT(MBR_NM, comma_location - 1)) AS MBR_LastName,
 ...

Hmm, now that I think about it, you can probably get away with specifying a WHERE/JOIN condition on the client_id in the claim_line table, since SQL will likely still do...

Yep, you are close already.

And, in fact, your existing clus index on the claim line table is preferred IF:

(1) claim numbers are all unique (i.e. they never repeat across clients)

AND

(2)...

How much fragmentation depends on how INSERTs are done.  Singular INSERTs will see more fragmentation than multi-row INSERTs.  Either way, you can mitigate this with partitioning (based on the clustering...

You're on the right general lines, but you don't really need partitioning.  Typically what you need for best overall performance is the best clustered index on all the child tables...

That's not factually correct.  NOLOCK prevents having to take, and release, that shared...

RETURN works only within a stored proc.

You could switch to a GOTO:

IF EXISTS(SELECT 1 FROM dbo._proc_control_table WHERE Proc_Name = 'sp_Populate_NEW_NEW')
BEGIN
RAISERROR('This proc is already running, please wait for...

Is the code inside a stored proc (as stated in original post)?

The RETURN statement will exit the proc.  The -1 is a return code that can be checked by code calling the proc to see if an error occurred.

Easiest way would likely be at the start of the proc, write a row to a control table.  At the end of the proc, delete that row.

If the proc tries...

Nvm, just saw the follow up comment from OP.