So, I don't think I've personally confirmed it in K1, so I can't say. However, from ... other things ... I expect the issue to be the same. I would love to know if anyone does a conclusive test.
Just to be clear, the thing is, the engine loads the bumpmap from the TXI ... but only for the texture defined in the model. So, when you are using the appearance to specify a different texture that is not what you have for 'bitmap' in the model file, then it will only do whatever the TXI file for the original texture specifies. So if you are using the same bumpmap on multiple appearances, nothing will really seem wrong. I originally encountered this when I was trying to get different cubemaps on each protocol droid reskin I was doing, and then we actually realized what was happening when DarthParametric was experiencing some crashing issues with his outrageously high quality normal maps.
The reason this happens to HK-47 in K2 and not K1 is that the K2 version of the HK-47 model doesn't specify any diffuse textures in the model itself! All NULL. This makes it so that there is no way to get an envmap other than using the appearance.2da column. It's also the issue that makes it so the sith war droid only has a gun texture w/ its 'base' coloration, but with each of the 3+ other colors, the gun model it carries winds up textured with the droid texture and not a gun texture. My personal takeaway has been that it's probably better to remake a model for each custom texture rather than to use appearance.2da, at least until we figure out what the model loader's limitations are...
This would actually be a pretty easy/convincing test to run in K1, just NULL out all the bitmap entries for a model, compile it, put it in game (make sure appearance.2da envmap column is set to default) and try to get envmaps via TXI. Or even just recompile the K2 HK-47 model for K1 (for testing purposes) and test using that, since it already has null diffuse textures throughout.