StratComm 's been prety much right on, origonaly I sugested, makeing the class as a seperate subobject, because I thought it might be too triky to get the textures in the corect order, but if you can get it done, this is the better method. he is wrong about the detail box thing though, they can be set up so that a subobject is or is not rendered based on it's position in the box, so you can have a high and low detail cockpit, or more simply, just have all the detailed bits in a seperate subobject that the hole it sits in.
Nuke is corect in that fewer textures == fewer passes == faster == better, however, puting transparency on the same map as will be seen through the transparency is asking for trouble, it might work, it might not, it's what's refered to in the computer science world as 'undefined behavior' there is no way to know in what order the polies will be drawn, keeping them to one part of the texture will make no diference at all. currently, the polies are drawen in what ever order the BSP compiler happened to make it's tree, there is no definition on how this is done, so there is no way to setup the polys so they draw corectly, though you might get lucky. in the future you will have the option of determineing the draw order of polygons in a texture, you will have the options 'front to back' (for non-transparent textures), 'back to front' (for transparent textures) and 'none' (can be faster than resorting for non-transparent).