Also, until the Sourcegear folks gave up on it, Veracity. It's not quite as monolithic as Fossil is (Fossil is just one executable file), but it had version control, wiki, and issue tracking built into it as well. It was also distributed.
> When they both push their changes neither one will get some notification that the other handled the bug in an entirely different way.
They'll get the notification (in timeline by browsing it or via RSS) once they sync.
> I believe this is the strength of centralized ticketing, the ability to know that the ticket you are reading contains all the currently available information regarding a ticket.
I don't think this situation is very different from this with the central bug tracking: user B reads the ticket, decides to fix it and goes coding. User A closes the ticket. User B pushes changes and goes to the bug tracker to close the ticket as "fixed", but finds out that it was already closed by user A without code changes. So he updates the ticket with status "fixed" rather than "won't fix".
> Fossil looks very interesting and looks like it would work great with projects that don't have many bugs coming in from users outside those handling the code. But I don't think it's ready to handle a large project that receives many tickets from outside non-dev users.
You're right that currently there's no example of such project powered by Fossil. Some improvements to tickets are needed for this (it's being discussed in mailing list), but I think Fossil will be ready for this in the near future.
There's also Veracity that's trying to do distributed-everything.
Both Fossil and Veracity and integrated issue tracking. Both are also DVCS's so they are in effect competitors to Git. They are both open source however so the Git community could do something very similar to what they did.