because there was no schema change or update stats
How did you verify that the last part? Keep in mind that autostats can kick in often. In my experience, it is uncommon that queries run with multiple plans during the course of a day. This is particularly true with temp tables, since they often trigger recompilation.
For a list of other recompile reasons, see this query:
SELECT * FROM sys.trace_subclass_values WHERE trace_event_id = 166 AND trace_column_id = 21
As for avoiding this in the future, you need to review your queries very carefully. Yes, that can be quite a daunting task. You first need to understand why this plan changed. The interetsing part is not what triggered the recompile, but why you got such a bad plan. Most likely the query was sniffed for a value that is untypical. So while the plan was good for the sniffed parameter value, it was not good for more commonly used parameter values.
I'm not sure setting up a mail alert is the way to do. There is a report in SSMS for regressed queries. You can also write your own queries against the Query Store tables.
Further reading: I have written about parameter sniffing in this article: https://www.sommarskog.se/query-plan-mysteries.html.
Enrico van der Laar has a series of article on Query Store on http://www.simple-talk.com/sql/database-administration/the-sql-server-2016-query-store-overview-and-architecture/. I think this includes some overview over the QS tables.
Hi - I am looking for the TSQL that is used internally by the native SSMS regressed queries / queries with high variation reports, so that I can work on some kind of automated reporting/alerting to be more prepared for this kind of situation.