This behaviour by W3TC hasn’t been reported previously, and we’ll need to look deeper into the issue to see if there might be a way to prevent this from happening on our end. There’s also a possibility that a certain specific setting in the caching plugin is causing this, not the entire plugin per se – which is another thing to check out for us (and there are quite a few settings in W3TC, as far as I remember ?? ).
It’s unlikely that the caching plugin is somehow messing with the popup itself, since the latter is generated via PHP, not JS – by fetching the content of a specific page, which in turn is set in the Theme Options (Customizer) as a WP setting (i.e. a database entry). What can be going on is the caching plugin “remembering” previous versions of your pages (together with the popup content generated on them), so that when you change the popup settings those changes are not reflecting on the live website right away, causing general confusion.
A possible solution comes to mind in this light: trying to set the cache expiration/auto-purge options in such a way that any back-end changes are faster to manifest themselves – or simply purging all caches after any back-end change you make. Speaking of which – I’d recommend disabling the caching plugin completely for the duration of active development, and turning it back on only after the site is in a stable version and only new content is being added. This is a standard best practice applicable not only to this particular case, but to almost any WP project, and I follow it myself as well.