Okay, my dislike for internal is well known at this stage, I believe. What I want to talk about today is the process of stripping (ignoring) the internal keyword. As I have recently discussed, I have recently run into several situations where certain parts of the framework, marked as internal, would have been so very useful to me.
A while ago I stripped internal out of SqlCommandSet, and I have used the same technique since. It is a hack, mind you, but a very useful one.
Now, we can make use of internals in the framework if we use Reflection, but that has a perf cost to it. I found that by caching the results of the Reflection, and a bit of delegates, we can fairly easily expose the required functionality out, without paying a high price for performance. SqlCommandSet is a good example of this technique in action, and it has been wildly successful.
Another, a more advance version, but one that I don't know the ROI for, is to use Lightweight Code Generation to add accessors to the internal methods already there. I am pretty sure it is not worth the trouble.
Of course, if it is internal, you have to make sure that there are tests around it, because otherwise it could change without warning and you'll not know. There are other issues with the method, mostly around support, robustness (the internal code may make assumptions about its use), etc.