As to an explanation of what was going on... this might be a bit lengthy and part of it is "thinking out loud." I am discussing this only because you mentioned that you used timers on your forms. For active timers and performing development actions, that is like oil and water. They simply do not mix.
Timers tend to be problematic when running in the background, particularly if they are "fast" timers - i.e. short intervals. When developing, you almost certainly do NOT need a timer running. However, you said you had removed the timer from that form. Did you also remember to remove the part that loads the timer interval slot? In any case, you should ALWAYS set up your timers so that they can be turned off for development. Further, it doesn't matter if the form you are developing at the moment has its timer turned off if another form is open in the same project is open in the background and still has ITS timer running. Timers don't just affect a form - they can drag down performance on the entire project.
When I see errors in compilation such as you showed us, I look to the functions called out. In the line that was highlighted yellow in post #21 of this thread, you use CStr(), CLng(), Len(), and IIf(), all of which should be in the VBA library. It would be impossible for you to run ANY VBA code at all if that library was missing. The preceding statements had Left() and Right() functions that are part of the same VBA library - but that statement DIDN'T get called out.
This behavior is indicative of either of two errors. The first error is a type of code corruption that hits randomly and can often by fixed by the DECOMPILE/RECOMPILE process I referenced earlier. The second error is that another library is corrupted in some way. When you are compiling or running the code, Access (behind the scenes) searches for the data needed to validate one or more of the procedure calls, but when it passes over the "screwed up" library reference, it stops and says "invalid procedure call." Not because your call was wrong but because something else stopped it from finding the correct information. That is why earlier I mentioned looking for missing/broken references. This kind of error happens all of the time when there are bad references in the mix.
I have not had that much difficulty with Compact & Repair but if you have timers running ANYWHERE during a C&R you might have issues. We have occasionally noted that developing with active timers caused unexplained corruption. I don't know that a C&R while a timer is running would do that, but I wouldn't rule out at least some corruption potential.
You reported that wiping out the contents of an old but working DB followed by copying everything from the "wonky" DB to the cleaned-out DB worked until you did the C&R. Despite arnelgp's skepticism, I have to say that this cannot happen with any regularity because it is the kind of DB problem that Microsoft would HAVE to fix. AND if it happened often, they would be able to test it more easily. So while I don't doubt your report that a C&R "broke" a working version, I would suggest that something was still active during the C&R and the two active processes interfered with each other in some ugly way. You might want to think about that and remember to do C&R under circumstances that NOTHING in the project could still be active.
I've rambled on a bit, but this leads me to advise you to recheck you project for remnants of those timers. They are great for production but terrible for development.
