So the short answer is that this simple design will in fact work and will in fact turn in either direction but once it's turning the inertia of the rotating part will keep it going in the same direction even under some load. However as others have pointed out a real-world DC motor will almost certainly use an improved (but more complex) design that ensures that the motor will always turn in the same direction and avoid arcing, and I have also disassembled real DC motors and seen this for myself.

Regarding the shorting of the contacts during the crossover, this did also happen with my motor however it doesn't stop the motor as again the inertia will carry it across. However it will cause arcing between the brushes and the contacts and create a sudden high-current spike on the power supply, both of which are a bad idea. In my case, adjusting the size of the contact area between the brushes and the contacts so that it was smaller than the gap between the two contacts avoided this.

This has somewhat been covered in some of the other answers and comments but I would like to add that I have in fact built such a motor and it does in fact work. Once the motor is up to speed, the inertia of the rotating part will keep it turning in the same direction instead of reversing direction. If I remember correctly, this design of motor can however be started in either direction (e.g. if you stop the shaft with your fingers and then flick it back the other way).

@Mast "not AC" and "DC" are the same thing.

@Mast it is not irrelevant, because it explains that DC signals have more power than AC signals which is a major cause of speaker damage from DC signals.

Generally it's a good idea to allow for recalibration in case something gets messed up the first time round, or the system needs to be recalibrated for a different setup or to compensate for hardware ageing etc. I, for example, tend to mess calibration up the first time because I don't know what I'm supposed to be doing.

What is your motivation behind preventing the code from running a second time? Is it important that the code cannot be reverse-engineered, in which case setting a flag to bypass it may not be secure enough? Would running the code a second time damage the hardware? Is it a UX thing, like to display a tutorial message the first time the system is used, in which case it might be desirable for the "factory reset" function (if present) to trigger the code to run again?

I didn't think that the question was asking about a strict Von-Neumann CPU but rather a practical one, like the x86 or ARM, which are loosely Von-Neumann. In the case of a strict Von-Neumann, without any internal registers, the ability for the CPU to keep running during DMA comes down to my second point in my answer, that the DMA is not using the entire memory bandwidth.

@CortAmmon I believe that dual-channel memory is usually spread across the physical address space, so for example if you have 2GB of RAM then the lower 1GB is on the first channel and the upper 1GB is on the second channel. In that case, if both the CPU and the DMA want to access the same 1GB area of memory, they will be on the same channel and thus potentially conflict.