semicolon prior to CTE

The semicolon is needed for scenarios where WITH could be considered part of the previous query. Many people now put one ahead if any CTE, but this can even cause problems. It is always best practice to end SQL statements in semicolons, rather than prepending them to the following statement.

The situation with CTEs is interesting because a preceding statement that doesn't support WITH hints, such as the BEGIN statement, or a SET operation, could let someone who considers that CTEs start with a semicolon believe that there is some inconsistency in the CTE construct.

I think you'll find that a variable assignment without a FROM clause may not support WITH hints, and that this is the cause of confusion.

Every statement should end with a semicolon. Writing statements without terminating semicolons is deprecated and will not be supported in future according to Microsoft.

Having said that, there is at least some room for doubt about what "every statement" means. In previous versions of SQL Server certain statements were not allowed to be terminated with a semicolon. Now some require it but in most places the syntax checker doesn't mind either way.

Microsoft has created a legacy of problems by not having better rules and syntax checking. Even though not using semicolons is deprecated there is still no built in way to check for it so unfortunately people will continue to produce non-conforming code. Basically it's a mess and I suspect it will take several versions to sort this out properly. Meantime my advice is to put in semicolons wherever you can.

Is there any chance we could see the code (perhaps after being sanitized)?

Generally in SQL Server a semicolon is required on the last command before a CTE, unless the CTE is the first element in a batch. This means you do not need a semicolon on a CTE that is immediately after a GO statement since it is starting the new batch. Of course, that should not happen in a stored procedure, but you could get a similar effect through the use of dynamic sql. Every time dynamic sql is executed, it does so in its own batch.

As a habit, I always start the line that the cte is on with a semicolon, this makes it a nonissue.

Sure. I've included the key part of my SP; the snippet prior to my new CTE and the CTE itself. Basically, I later email @IncorrectAssign and @DuplicateEntires to a few people via sp_Send_DBMail.

Select @IncorrectAssign = Count(*)
From d_People p1 Inner Join d_People p2 On p2.SupervisorId = p1.EmployeeId 
    And p2.EffectiveDate = p1.EffectiveDate And p2.EffectiveDate = @FromDate
    Where p2.SupPeopleId <> p1.PeopleId
Select @IncorrectAssign = Coalesce(@IncorrectAssign, 0) 

;With DupEmployees (EmployeeId) As
(Select EmployeeId From d_People
    Where Effectivedate = @FromDate And EmployeeId Is Not Null 
    Group By Employeeid Having Count(*) > 1)
Select @DuplicateEntires = Count(*) From DupEmployees

As a bit of a side bar, I deplore the fact that Microsoft is moving in the direction of requiring semi-colons for each statment. I guess it's better than requiring continuation characters at the end of each line, though.