Brion vibber wrote:

Individual paragraphs, table cells, etc would be an even nicer fine-grained level to do inline editing on, but this requires having a reliable way to associate parts of rendered output with the parts of source code which created them.

I'm aware of these difficulties. There are a number of ways I can see this being tackled. Firstly, only pure wikitext can be edited inline. That is, if you try to edit some text which is the result of 2 #switch's inside 6 nested templates being transcluded through 2 articles, then there's just no option to edit inline. Either that, or attempting to edit that part inline sends you to an appropriate edit page - either for the article, the template, the nested template, etc - more difficult.

But focussing on the easy stuff: inline editing on a page with nothing but nice, pure, transclusion-less wikitext, I don't see this as being so hard. Obviously the renderer renders the code for inline editing into the output, so there wouldn't be a correspondence issue.

For instance: for every paragraph, or the contents of every table cell, the renderer can output some funky code that allows inline editing on that part. This funky code is ultimately a function with inputs for two numbers that define a range of characters in the wikitext that will be replaced by the result of the inline editing. The renderer obviously renders these numbers into the output as constants when it parses the wikitext.