I’d argue that it’s incorrect for a CI process to alter production, even if it’s snapshots themselves are behaving as expected according to the design.
1 - I saw that, but I also saw this comment, which indicated that SlimCI treats all snapshots as modified during every CI job, which would mean my entire dag would need to be built every run CI run. This would also snapshot every table in production on every CI run, which could be fraught with side effects.
2 - I thought about that, but it would start out empty and thus all CI jobs using snapshot models would fail, unless I manually maintained/synced the CI schema. 
… I suppose I could set up a dbt operation to zero-copy-clone my prod snapshots and have that run as part of my prod build job. All CI jobs would use the same schema (to avoid the dynamic problem), so in principle there could be conflicts if multiple CI jobs were running simultaneously; but I don’t expect that would be an issue for me. I might try this approach…
3 - Honestly, snapshots feel like they were left behind in the run up to 1.0. I still get annoyed when I have to write them and re-learn that many config.yml options are ignored and I have to put them in a jinja config block. It almost feels like they should just be normal models that use a dbt-supported snapshot macro with some guidance around when it’s appropriate to use them (e.g., save them in a permanent location that can be archived and not in a transient tables).