Could renv::restore() error early if R versions recorded and used are different?

[etiennebacher]

I was trying to reproduce a project on a coauthor's laptop when we had an error about Matrix installation. It was not obvious that the problem only was that the R version recorded in renv.lock and the R version used were different. Running renv::status() would have informed us of this discrepancy, but I think renv::restore() could also be noisier about it, and even maybe error early in this case.

The usecase I have in mind for this is sharing a project that one can run without being very familiar with R or renv, basically "run this script to restore the project and run everything from data processing to results". Usually (in my field at least), software requirements are stored in a README. Supposing someone doesn't pay attention to the R version they're using, having an early error like "Couldn't restore the R project: R version stored is x.x.x and R version currently installed is y.y.y" would be helpful.

What do you think about adding a strict parameter (or similar) to error early if there's this kind of discrepancy?

Might be related to #2056