If we have a control with a button. And we have another control exactly the same.
C1 and C2 ... with ID's pc1 and pc2, C2 has a button with ID "but" and text value "ButC2", C1 has no button for the moment.

We create those controls in a aspx file.

Now, in C2 we want to access the button in C1 - so in C2 we put

C2 thisc2 = (C2)Page.FindControl("pc2"); // need to get the actual control from aspx page.

NOW I am going to try to retrieve the txt from the button in control2 using FindControl
Button thisb = (Button)thisc2.FindControl("but");
HttpContext.Current.Response.Write("Button text is :: " + thisb.Text);

writes out our button text "ButC2"

NOTE :: the only way that we can get to this Button text without making the button public and accessing it directly is to use the ID property of it.

BUT :: As soon as we create any other instances of C1 we immediately duplicate the Buttons ID and cannot use the above code.

NOTE :: That this is the best case scenario as we do actually have the actual control thisc2, which, in itslef should give us the uniqueness we need.

Thus ... if our button was instantiated with the control as Button b = new Button(); we 'should' be able to get to that button using thisc2.FindControl("b"), or at the very least when we do give it an ID, say "but", then, when we do use thisc2.FindControl("but") it SHOULD know that we are searching for a control names "but" within the container thisc2 AND NOT for any old controls lying around that may be called "but".

We immediately limit ourselves to a single usable instance of the control C1 because we cannot duplicate the ID.

The ONLY way we can get round it is to construct our control as C1(unique) {{ unique coming from loop or whatever }} and pass that on to the child controls within.
But we need to do this for every control we ever make if we are to use it more than once in an app and be able to find it using FindControl().
And then we have the problem of keeping track of them all, since they are all unique.
i.e. in the above example again, if the ID of the required Button had been given something unique and generated then how would we know what to find ??
thisC2.FindControl(??????) - unless we create a strategy whereby the naming convention we use gives us easy access to that uniqueness. Perhaps constructing these controls and passing in, as the unique part to append to the ID, a string consisting of assembly.namespace.class.index - which is EXACTLY what I has assumed that the framework would give as a default ID for any control/child control - a set up used by every OO language in existence.
Why are we using FindControl() at all ???? Why ?? Because it is good paractice to make things private or protected and public is a swear word ??? By NOT making things public, and using Properties and FindControl(), we cut off our access to these things and then have to go an invent a great big indexing schemw so we can get to them.

Is it me, am I being thick ?? am I missing something ?? or is there something wrong by design here ?