Modification_Counter influence the Cardinality Estimator?
How does the modification_counter influence the CE to take a different execution plan?


One way this can happen is that the new CE in SQL Server 2014 may interpret statistics differently depending on how many modifications have occurred on that column since the last statistics update. From Seek and You Shall Scan Part II: Ascending Keys by Itzik Ben-Gan:


  The new cardinality estimator identifies that the query filter exceeds the maximum value in the histogram. It has access to the column modification counter (call it in short modctr), so it knows how many changes took place since the last refresh. When the column is unique and of an integer type or numeric with a scale of zero, SQL Server assumes it’s ascending. So it interpolates the estimate based on the distribution of the values within the existing histogram and the number of changes that took place since the last refresh.


I cannot say if that behavior is leading to your issue. You could try running both queries with trace flag 9481 to see if your issue is caused by something new in the 2014 CE:

OPTION (QUERYTRACEON 9481)


You can also use query hints to force what you think is the better plan. Comparing the hinted plan with the unhinted plan may give you a clue as to why SQL Server is choosing the different plan.