Some testing has been done with the new release, and the holding of the ballot without returning it until the scroll is finished is a BIG problem. With a short race title, it will hold the ballot for about 8 seconds; for a long race title, about 15 seconds. In the strongest way possible, I object to this.
I'm not enamored with the scroll. It's hard enough to get pollworkers to be able to read static displays on the LCD, let alone a scrolling one. A static display showing the beginning text of the race title should be sufficient. The voter will be gone by the time the ballot is returned, and anything which creates the need for additional pollworker training should be nothing less than desperately needed.
As far as it being an optional feature, or setting up some kind of asynchronous code solution so that the ballot is returned before or during the scroll, these seem like complicated solutions to what ought to be a simple function. If it's optional, then a new flag has to be put into GEMS to program for it. The possibility that, "...making the display code asynchronous...would break other things." (Guy) should give pause as well.
Sorry to jump in so vehemently, folks. I don't know that this request is all that popular. I welcome other opinions.