I don't know if this is a bug or a feature (thanks for the FUG thing!) but we found recently something quite disturbing to us.
DefaultTimeTrackingIssueUpdater manipulates the 'timespent' at the issue generic value level, e.g.
(line 66, line 100, etc)
In the same time, at the issue level, 'timespent' eludes the normal updates from the issue generic value, as it can be easily seen here, in the IssueImpl:
This allows very easily to have 'unsynchronized' issue fields and time-tracking information in the worklogs. The normal way would be for the issue to receive updates directly from the TimeTrackingIssueUpdater implementation.
In our opinion this is wrong since this layer piercing (this is how I call it, don't know if it's the proper term) represents a potential source of many bugs.
If you need a test case, let us know.
Edit: The test case.
Place the postfunctions as seen in the attached image: the one that adds to the WL first and the one that only prints the issue field last (choose a transition, my favorite is 'Start Progress').
Execute 1 1/2 cycles on a newly created issue: Start->Stop->Start
Output in the logs:
Now, the problem is that it remains the same...  should add already 3600 seconds on each cycle, i.e. should be: