Hi @rloverin for your first package, what we do is leave the old package in place but hide it / unpublish it so as to maintain the user history and then add the new package. Once hidden it should maintain the same # of lessons/objects to complete; so little impact to users.

As for the 2nd, while in some cases where there are minimal updates to your package, you can overwrite and still maintain user history, you need to be very careful when do this and make to test it thoroughly before you make the change. If you have a sandbox, I suggest you carry out some tests there...if not, you can duplicate the course, take the course a few times, perhaps with a few test accounts, then make your updates. This way you will see exactly what the overwrite maintains or deletes, etc.

My personal guidance is that if the update doesn’t contain any significant material changes, I simply overwrite the file. If the edits are material changes, then I usually push it into the Central Repository and create a version of the training material (I generally put v2_24Aug2022 or something similar for version number) so if you were to look at a training material report you can see when the new version was pushed as v2, v3, v4 won’t mean a whole lot a year from now. Then you can push the new version into the course. It will reset anyone that was in progress, but hiding the old and adding a new requires them to restart with the new anyway.

I personally don’t hide the old training material because if it’s not a material change, I don’t care about who completed what “version” and if it is a material change and you do the versioning as mentioned above, you have that data all in one training material for reporting. I personally find the hiding of training materials to be messy over time as you might have multiple hidden training materials in a course after a few years. 

Just my 2 cents - hope it helps!