@WardBrian @rok_cesnovar Looking at the amount of package failures that are going to be caused by the deprecation (109!), I think there’s merit in delaying the deprecation decision until RStan 2.26 is on CRAN. Given the popularity of RStan, we’re at risk of fragmenting the userbase if we remove the syntax before RStan is compatible (or even if the removal happens closely after RStan becomes compatible).
Given that the current CRAN rstan isn’t compatible, it means that we can’t start updating package syntax in advance either. This would likely cause rstan to fall behind the main versions again even once 2.26 and then 2.31 is released, since we’d be waiting on package maintainers to update (or merge submitted patches) for the deprecations.
By waiting until 2.26 is on CRAN and giving us some time to submit patches for maintainers, we can start reducing the version gap between rstan and the other interfaces.
I don’t think this would be too unreasonable, or unduly delay things, given that the downstream failures for 2.26 are down to 17 packages (counting rstanarm) which all have patches merged or waiting to be merged. But it could be worth contacting Ben to get a more accurate status on the submission