• take a command pod or anything else
• add an MFT A or B tank to the screen somewhere, or attach to the first part
• clone it (alt-click)
• place the clone tank on the first part
• try to remove it again...

It will attach permanently and you need to delete it and the part it was attached to.

Hmpfff.. this is a stock bug it seems... never noticed before... please delete :(

The more I test stuff, the more I am beginning to get annoyed with KSP.

This -could- be an SSTU plugin related problem; I've seen similar happen when I clone a part and it null-refs during the cloning; it will do strange stuff after attaching (if it attaches at all).

Were there any null-refs in the log during this?

Can't say as I've seen it happen using stock parts, but then again, I don't use stock parts very often (3/4 of them are removed from my dev setup so that it loads faster).

Just to avoid getting this mixed up with the stock issue: I have confirmed the stock issue happens when cloning a part that is not attached to anything - if you clone an un-attached part, then attach it to something, it cannot be removed.

Me too. I just tested with only stock parts and the problem is still there.

Okay, thanks much for the investigation and confirmation. Re-closing for it being a stock issue.

I tried with two stock parts and they did the same thing, so I doubt it is SSTU related unless it affects other items in the screen.

It could if you still had the problem-causing SSTU parts on the craft.

KSP is setup up a bit strange in that one part causing a problem can manifest other problems on completely unrelated parts. Most other games/etc that I've worked on would just crash when the first part/module had its problems rather than continuing to run and manifesting problems for other unrelated stuff. (Which is also my general philosophy on programming -- if something is an error/absolutely not supposed to happen, then crash... .don't just swallow the error and propogate the now corrupted state by continuing to run the program; just crash it and let the user/dev know exactly where and what the problem was so that it can be fixed properly).

I will follow your guidelines above and see if I can reproduce the problem when next I have time for testing stuff (likely this evening).