Why force a choice? Surely you can move forward, offering layout flexibility but without necessarily breaking existing text?
It would mean some (small amount of?) extra work on your part, no doubt, but not breaking the golden rule of backwards compatibility would surely be worth it. Declaring my own vested interest: I re-write some of the synopsis text gathered by your program, or I write my own, so I would prefer not to have that input trashed, at least in the short term. But I would also like greater layout flexibility. Difficult choice, so don't force the issue.
1. Provide a non-expiring copy of the existing code, for historical stability. Call it something else if needs be. Move on.
2. Offer the user a settings tick box "Use flexible layout". You would need to maintain two layout engines, but the current one already exists.
3. Keep the existing "synopsis.guikuo" file name for historical layout, use a different file name for flexible layout. Maybe in conjunction with point 2, if synopsis.guikuo exists, render historically, otherwise use flexible layout.
4. Provide a default flexible layout template that matches the current historical layout. Provide also a GUI Builder utility to search folders and parse synopsis.guikuo, if it exists, reformatting the text in it to the default layout template. In other words, auto convert existing historical synopsis text to a new flexible layout.
Finally, thank you Guy for all the effort you have put in and the ongoing contribution you continue make. Your work is greatly appreciated. Something worth noting, you could always call on the community to help, if help is needed. For instance, providing a stand alone conversion tool to reformat historical synopsis.guikuo content to a newer layout.