I can give you a scenario where it happened for me. I had a SharePoint Content Editor web part that was exported as a .dwp (which has content wrapped in a CDATA) and needed to insert this into a Visual Studio deployment package, the target spot for this in the Elements.xml file is also a CDATA. It's a bit silly because it's just HTML in XML in XML but then it's SharePoint so silly is the normal state of being.
So just in case this leads someone else to this page I thought I'd summarise the solutions I came up with:
1) XML encode the inner CDATA so you don't need the inner CDATA. Might not always be practical but worked in my case.
2) In this case there was a another option, move the content of the Content Editor web part to a separate file and link the Content Editor to that web part file. I guess this falls under the rethink your strategy approach.
3) The above idea of splitting the whole CDATA into three separate consecutive CDATAs. While this is a clever idea and would work for general cases, I'm not sure this would work in my case. This is because the content was going to be passed by 2 different processes, the deployer and then the page manager. The deployer needed to take the content of the outer CDATA and pass it whole to the page manager which would then take the content of the CDATA as a single element value. With the 3 CDATA approach the deployer would have treated the whole content as a single XML structure and so the HTML actually gets interpretted incorrectly. (I hope that makes sense).
CDATA
sections. Why would you need to? – ExpurgatoryCDATA
sections? – Expurgatory