Covariance structure information is currently stored in merMod objects as attr(fit, "cov_structures"). This is lightweight (it doesn't affect the definition of the merMod classes), but also has the potential to be fragile — in particular, I noticed that lme4:::refitML.merMod (which finds all the bits of a merMod object it knows about, manipulates them, and then calls new("lmerMod", ...)) doesn't preserve these attributes; in particular, this (a simplification of the test on line 36 of testthat/test-methods.R fails because it calls refitML for an object with complex covariance structures.

fit <- lmer(Reaction ~ 1 + (Days || Subject), sleepstudy, REML = TRUE)
profile(fit)

Architecturally (i.e. if we were starting from scratch) it would be more natural to make "cov_structures" a new slot rather than an attribute. However, this would break backward compatibility. We could either:

• accept that attributes are somewhat fragile/hacky, modify refitML to handle the attribute safely/correctly
• redefine merMod to include an @cov_structures slot, write an up2date function (or some such: there's one in glmmTMB which has a similar use case, although it would be nice to avoid masking/name clashes: maybe make up2date an S3 generic ... ???
• do something tricky by writing an extended class definition (flexMerMod?) that allows structures both with and without cov structures.

The third is most elegant but also the one I know least about how to implement sensibly ...