First level of smarts.... use releases
Found in and fixed in are fields that are typically not updated that much. You describe it when you find the bug, update it (maybe) when you've diagnosed the bug, and add "fixed in" when you verify the bug. The biggest use of these fields comes after the bug is closed. This gets looked at when, for example, a customer issue comes up and someone wants to know if a bug existed in a given release. What you really care about capturing easily is what releases the bug can be found in, and what releases a bug is fixed in. In many development environments, this translates to branches (with one or a few releases per branch). So don't worry about build numbers - those can go in comments. Worry instead about releases.
Second level of smarts..... multi-select
In some defect tracking systems (RT, for example), found in and fixed in are single-select fields. This is wrong. You can certainly have a bug that is found in more than one branch of code. And you can have a bug that is fixed in more than one branch of code. For example, maybe a bug was fixed on head and the most recent release branch. The bug should note every release that is known to contain the problem and every release that is known to fix the problem (note that "head" means "all go forward releases branched and taken from here").
Third level of smarts... different resolution types
This is the level that I have yet to see a defect tracking system actually support. When you're working with a bug, you may find it in the 3.5 branch, the 3.7 branch and head. And then you may decide to fix it on head and the 3.7 branch, but not to fix it on the 3.5 branch since you're not intending to release 3.5 again. How do you close the bug? Is it fixed? Well, yes. Is it deliberately not fixed? Well, yes. Or did someone just screw up and accidentally not mark the "fixed in 3.5"? In this case, no, but we're all human and that's going to happen some day.
You basically need one resolution type per "found in". Think something like this:
Found In Resolution
3.5 Won't Fix
Anyone know of a defect tracking system that does this? Or is it good enough to just put this information in the comments in case you need it later?