What I'd like to know is that, as far as I know, the last update didn't include any FSS changes. So, how can such serious bugs be introduced in to an area of the game that should have remained untouched?
Being an old fart and coming from an era when code was one monolithic block, this is one of those things that took me a long time to accept. But it seems to be a consequence -- arguably an inevitable consequence -- of the way modern software is developed, with code branches being independently developed by different teams and then recombined into the trunk. Sometimes things get out of whack.
I first stated seeing this with Apple software over a decade ago; bug in iTunes and later in iOS would be fixed, only to resurface one or two revisions later. Sometimes these were functionally similar bugs introduced by new code, but in many cases the fixes and workarounds were so identical to the earlier problems that it was clear the exact same code was at play. The FSS barycentre bug seems to fit this pattern; it was there in beta, gone in the final release, returned with the first patch.
It's sort of obvious, when you realise that new features might have been in development for a long time on older forks of the code, that when they're rolled back into the main project it's possible for previously fixed bugs to roll back in with them. In theory good project management should prevent this, but in practice these are huge projects and it doesn't surprise me that it sometimes goes awry.
It's also possible for extant bugs to have their combination of triggers removed by seemingly unrelated fixes elsewhere (hence the "we can't reproduce this in our build" problem) only for another change further down the line to reintroduce a triggering combination. But these are rarer. Much more likely it's the result of a problem with forking and recombination. The good news is that it's normally much easier to find and eliminate these than it would be for a new bug.
