As a follow-up, would you be open to the following upkeep actions?

I could do a PR fo each of these before you finalize the v4 interface.

• add dontrun to failing examples for now to pass CI (CI progress #779)
• Use a very simple testthat setup to help detect errors (i.e this would just help to ensure things do not break. (CI progress #779)

this would be very helpful to be able to see what passes and fails depending on the OS, package version.

I know tmap is probably difficult to manage and submit to cran.
We can use skip_on_ci(), skip_on_cran(), skip_on_os("windows"), skip_on_os("linux") in the appropriate places.

I think these would smoothen transition from v3 to v4.

• Move the build/ folder to data-raw and remove rgdal. i.e. build them with sf? I don't know caveats for that or consideration for backward compatibility of older spatial objects. (Spell check + move build to data-raw #782)

After that, in my opinion, it may be easier to address outstanding issues more efficiently by knowing exactly what's failing and without the fear to break something silently.

• Creating failing tests of the required behavior is a good way to have a todo list!
• Add any documentation you think is useful, but difficult to manage on Cran as an article.

Again, feel free to close if you don't think you have the time to manage this.

I also suggest you create a new repo for tmap3 to host the documentation website there before release maybe and point people to the v4 replacement.

Edit: overall in #775, #779, #780, #782, #783, #784, #785, #786, #787 I did a round of upkeep to update the website, the documentation, internals, handling of suggested packages, to make future development a little bit easier.