This seems like a reasonable time to talk about how testing with Twine works. Initially, the test suite used a tool called Selenium that scripted actions in a web browser and verified the results. The problem with this approach is that it has turned out to be both brittle and flaky. Brittle because I would make a change to a small part of the code and 5 tests would break sometimes, and flaky because there were often difficult-to-debug timing issues with the tests that would cause them to succeed some of the time, and not others -- on the same code. Not ideal.
(I know there are lots of happy users of Selenium, to which I say: good on you. But it hasn't been good to me.)
With the Twine 2.1 series, I've been focusing on unit testing, which isolates each part of the code and tests each bit of it individually. It's been a lot more reliable thus far, but it takes time to write all the tests. I've been focusing unit tests on the data layer, because bugs that cause data corruption are the worst in the world. They trash users' work and leave me feeling horribly guilty. I'm the dog that ate your homework.
(No, there isn't any way for an end user to change grid spacing, because it's always felt unnecessary to me... but it's always good to leave ourselves that option should we want it someday.)
Now the offending code has checks for grid spacing, and there is a specific test to check that it handles those situations correctly. So it shouldn't happen again. Let's hope. There is always a degree of uncertainty with software engineering.