Version of the script
Current dev branch. Also seen on a released copy from a few months ago, just before sp_PerfCheck was added to a release. I don't think this is new.

What is the current behavior?
I have seen queries that I know execute many times per hour, but that sp_QuickieStore's first result set reports as not having executed in days. When I use @debug = 1, I find that the LastExecutionTime and other time values in sys.query_store_runtime_stats are not reaching #query_store_runtime_stats. The temp tables before this point look correct.

The expert mode compilation_stats output has the correct execution times. I conclude that the error must be in how we populate #query_store_runtime_stats,

When I last saw this problem, it was when my only filters were on @Start_Date, @End_Date, @Database_Name, and @Include_Query_Ids.

If the current behavior is a bug, please provide the steps to reproduce.
I wish I could. I will try later. Hopefully, anyone with a big enough Query Store data set can find this on their own.

What is the expected behavior?
The LastExecutionTime in #query_store_runtime_stats should match sys.query_store_runtime_stats, subject to my date filter.

Which versions of SQL Server and which OS are affected by this issue? Did this work in previous versions of our procedures?
If it did, it was probably a super old version. I wonder if the partitioned_last_execution_time stuff broke it? But I can't see anything obviously wrong with the window functions. Maybe Erik will immediately see it?

IMPORTANT: If you're going to contribute code, please read the contributing guide first.
https://github.com/erikdarlingdata/DarlingData/blob/main/CONTRIBUTING.md
It has been a while. Maybe I should.