Rather than building special syntax to handle winter-into-spring growth, I'd rather combine this with the idea of growths replacing growths. A rough sketch:
[GROWTH:APPLE]
[GROWTH_START:100800:102800] A range depicting when the growth germinates. If omitted, starts when plant is planted.
[GROWTH_STAGE:APPLE_BUD]
[GROWTH_DURATION:50000:60000] Once germinated, the growth is an APPLE_BUD for 50000-60000 ticks.
Describe the APPLE_BUD growth here.
[GROWTH_STAGE:APPLE_FLOWER]
[GROWTH_DURATION:45000:50000] How long it stays an APPLE_FLOWER.
Describe the APPLE_FLOWER growth here.
[GROWTH_STAGE:APPLE_UNRIPE_FRUIT]
[GROWTH_DURATION:20000:25000] How long it stays an APPLE_UNRIPE_FRUIT.
Describe the APPLE_UNRIPE_FRUIT growth here.
[GROWTH_STAGE:APPLE_FRUIT]
[GROWTH_DURATION:25000:30000] How long it stays an APPLE_FRUIT.
Describe the APPLE_FRUIT growth here.
If the growth doesn't get picked or fall off by itself, it presumably withers away. There's nothing special about a growth that happens to survive into the following spring. In fact, a growth could take years to mature.
The main question is whether the stage timings should be cumulative, or all of them relative to the start date to keep multiple plants reasonably bunched together.
The current GROWTH_TIMING syntax can also be used for backward compatibility, but it retains its current limitations.