Well, the texture data could've been modified by the game's code between lists, so the texture could've changed.

The idea is simple: let's say I'm running a list and it says:

use texture A
draw this
use texture A
draw that
use texture A
draw more
use texture A
draw even more
use texture A
draw yet more
use texture B
draw something else

Looking up the texture in the texture cache is not free.  It may also cause a rehash check.  So, If we did it every time the game specified the texture cache, games would get slower.  Maybe not a ton slower, but I'm sure it'd be at least a few FPS if not more.

So, we only need to look up the texture when something about the texture changes - when we have a reason to think it's worth our time.  If it just sets the exact same details over again (this is common), we probably don't need to.  In fact, many (maybe all except block transfer) of the textureChanged things could probably be in a diff check, but I'd need to think about each one to be sure.

However, when the game queues a new list, even if it's the same address as before, it could easily be a texture address the game wrote new data to.  So it might've changed after all, even though it has the same properties.  So, I'm thinking it probably should set changed...

In contrast, framebufChanged can't really change between lists.  Well, hmm, maybe if it restores the context?  Hmm, that could be tricky too for textures.  Hmm, need to think about that...

-[Unknown]