Kerbal Space Program

Maybe I'm misunderstanding the point, because the color-coding on the linked GIF seems to show mipmap selection being done correctly.

It looks KSP is drawing to a 1820×1050-pixel window, and the part looks like the 5-man Apollo capsule from the mod Blue Dog Design Bureau.
This has a 2048×1048 texture file, of which the texture for one side uses a patch about 1000 pixels in width. So I would expect the graphics engine to choose the full-resolution mipmap when the part fills closer to 1000 pixels wide (close to half the display width) and choose the half-resolution mipmap when it fills closer to 500 pixels wide (closer to quarter the display width). That expectation is also what I see in the linked GIF.

When I load the part from that mod into the game, and look closely, the transitions look very good to me. I see no blurriness above what is caused by anti-aliasing onto the finite number of pixels. The text on the part zooms nicely, for example. I can only see popping between scales when I take the part outside and see the grooves under oblique lighting. That is, I can see transition between mipmap levels of the normal map. Stock parts also zoom very smoothly.

As ancassid says, there is a Unity option to bias the choice of mipmap, away from the usual choice of whichever scale best matches the on-screen size to maybe the more fine scale. But then we are asking the anti-aliasing filter to do on the fly what the mipmap generation was intended to do. I would not recommend an adjustment unless the more-artistic parts modders were in agreement.

An option to interpolate between the two nearest-match mipmap scales, tri-linear filtering, might be worthwhile for people with fast graphics cards and low-pixel-count screens.

Does any stock part show the symptom ? Is it blurriness, or visible transition between mipmap levels, or both ?

It is already known that the default mipmap bias in Unity is blurry (see this Unity Answers thread: https://answers.unity.com/questions/310352/texture-mipmap-distance.html). Also, MSAA has nothing to do with texture sampling, it only applies to the rasterization step when rendering. The GPU always samples only a single texel of the input texture maps for each pixel on screen, which is why mipmapping exists in the first place, to prevent the sampling rate from being too low. I might do some experimentation once I'm done with finals to demonstrate that the bias is in fact incorrect.

I'm not sure how stock parts are relevant to this

Changes have been made in 1.7 for part revamps, moving to RTT and please check if this is fixed.

I'm not sure what you mean by this? I don't see any settings for mipmap bias or trilinear filtering in 1.7, does that mean they were hardcoded?

To whomever works at either Take Two or SQUAD who maintains this bug tracker - PLEASE PLEASE PLEASE DO SOMETHING ABOUT THESE SPAMMERS!!!! Here we have a spammer that not only added a comment to this issue (not horrible) but also vandalized the description and wiped it out (AWFUL). Now we can't see the original description of this problem anymore.

^ Edited to original submission based on records in my emails. Had to change my passwords to get back in here too, I hope the bugtracker hasn't been compromised and people have had their data stolen.