This sounded totally wrong to me, so I did a check in one of my own environments and the results were fun! Check my test below to see if I missed anything:
I have some custom controls I made myself and brought into a separate Dev env through a managed solution. I then created a new Unmanaged solution in that target Dev env and added one of those custom controls from the managed import. I then exported (as managed) that new solution containing nothing but the custom control. Then, I imported that (new) managed solution into a third environ which did not contain any of the managed or unmanaged customizations from the previous two environs.
What I found was that it (surprisingly) did let me export that solution and (also surprisingly) let me import it again. But... the solution didn't actually contain anything at all because there were no unmanaged customizations to the custom control itself, so there was nothing to put into the customizations xml. This is fascinating because custom controls are just a code bundle and can't have unmanaged customizations, so it seems that once they get bundled as managed, these may indeed be the only solution component that can be rendered non-recoverable (neat!)
...but wait, we added that thing to a solution, isn't it supposed to come across in the solution? Actually, no. We added a reference to a component that is from a managed solution. If this were more than just an atomic test (for example, if we'd added the control to an unmanaged form in our solution) then we would get a missing component ref in Solution.xml that listed the managed solution that control was supposed to come from. That missing component ref is what is supposed to tell the target env to reject the import because it doesn't have the right managed solution.
...but wait, wasn't the original problem that this dependency was from an unmanaged customization? Yeah, that is weird--and a bug--for sure, but it is not the only solution component dependency tracking problem I have seen with custom controls. For example, as recently as a couple months ago I was still able to delete custom controls from an environ even when a form still had dependencies on it (haven't tested recently) which is a HUGE problem for the form XML.💥
...But wait... @prathyoo said "Interestingly the app still worked" so what gives? This still seems totally wrong to me and in my testing I have to insist it is wrong. When you bundle up the unmanaged solution in this way it DOES NOT carry the solution customizations that define a custom control, so there is no way it could possibly migrate a custom control from one env to another. Check out this screenshot from my test when inspecting the solution zip - note there is no Controls folder in this zip at all.
Now look at this zip from the original managed solution - note the Controls folder where all the PCF definitions are stored:
Now... I guess it is possible that the creator kit (as a first party solution) is somehow unique here and it doesn't need to move that way but I HIGHLY doubt that... so much so that I don't think it's worth the time to even test it. Far, far, far more likely is that someone just imported that solution without telling you, @prathyoo ...did you check your solution histories in the target env?
