I did a bit more research on this issue. Please note - I am using my own implementation of MultilineEntryElement which is probably a bit different than others'.
First, it's worth stating that the issue does not manifest for me in "simple" scenarios - where a MultilineEntryElement is placed inside a section which is created as part of the initial creation of the RootElement. The issue only manifests when I manipulate an existing RootElement that has already been rendered by the DialogViewController.
It appears that there is a bug in the way MonoTouch.Dialog computes sizing of rows. If an element implements IElementSizing, then MT.D will call its GetHeight() overload. Once MT.D has detected an element with "irregular" height, it appears to need to call this method every time it processes a change to the enclosing section. This can be expensive... So if MT.D lays out a RootElement and hasn't found an element that implements IElementSizing, it appears that (perhaps intended as an optimization?) MT.D will IGNORE IElementSizing information for any elements that are added POST initial rendering. So the CELL's RowHeight property will return a standard row height, and the MultilineEntryElement will render a UITextView that spills over the cells below it.
The workaround I've come up with is to create a simple element called DummyElement which implements IElementSizing and returns 0 for GetHeight(), and to add it to the initial RootElement before the initial layout happens. If you do that, MT.D will register that there's an element which has an irregular height, and call the GetHeight() method on your MultilineEntryElement when you later add it to your element "DOM".
Here is my minimal impl of DummyElement in case it helps:
public class DummyElement : Element, IElementSizing
{
public DummyElement() : base ("empty")
{
}
public float GetHeight (UITableView tableView, NSIndexPath indexPath)
{
return 0;
}
}