yeah, I have no idea why they thought this behaviour would be a good idea.
It is "by design" rather than a bug though
An example of a breaking change protected by compatibility level is an implicit conversion from datetime to datetime2 data types. Under Database Compatibility Level 130, these show improved accuracy by accounting for the fractional milliseconds, resulting in different converted values. To restore previous conversion behavior, set the Database Compatibility Level to 120 or lower.
Specifically datetime that end 3 are treated as though it was 3 recurring and datetime ending 7 are treated as though it was 6 recurring. datetime that end 0 are unaffected. (these were the only possibilities for that datatype as it has 300 "ticks" per second)
Restricting compatibility level to solve this single issue seems a sledge hammer solution. You can explicitly cast it to datetime2(3) to avoid this
DECLARE @LastSelectedDate DATETIME = '2021-11-09 13:52:29.187'
SELECT CAST(@LastSelectedDate AS DATETIME2(7)),
CAST(CAST(@LastSelectedDate AS DATETIME2(3)) AS DATETIME2(7))
Returns
+-----------------------------+-----------------------------+
| 2021-11-09 13:52:29.1866667 | 2021-11-09 13:52:29.1870000 |
+-----------------------------+-----------------------------+