There's actually a lot to this ticket. Here are the issues that I can see:

-the text box can get tough to work with if there's too much content. You can hold down within the text box to get a cursor that lets you scroll some, but that isn't terribly intuitive. I'm also experiencing scenarios where scrolling this way only lets me move one line at a time.
-when the text box is too big there becomes limited space to click on to dismiss the keypad. I have to scroll up to show the rest of the screen to find some free area to click on to get the keypad to go away.
-the keypad animates out and back when one of the toggle buttons is clicked to add some markup to the content (this is by design unfortunately; the toggle buttons receive focus when they're clicked. This causes the text box to lose focus which, in turn, causes the keyboard to collapse. To resolve this I added code that forces focus back to the content text box but we still have the keyboard blip. Ideally there'd be something that would let us create buttons that don't accept focus so this wouldn't be an issue).
-space is really at a premium for this screen, especially when the keyboard pops up. The "edit post" title should scroll with the rest of the screen or collapse or something.

We might want to experiment with navigating to a specialized screen when the "content" text box is clicked (maybe there's an edit button someplace close to the text box for example), which would offload some of what we're tying to do here. The new screen would support basic text editing and also provide the interface for adding mark up (as a note here, the ApplicationBarIconButton objects do *not* receive focus, so they'd make excellent candidates for markup buttons). After integrating the new screen we could come back and have the post content in a ScrollViewer + TextBlock.

There is also a limit on how much text we can display with the TextBox and TextBlock controls (2048 px IIRC)--I ran into that issue tring to display the EULA on app start up and had to use a WebBrowser control to display the entire thing.

I've attached a patch that has an example of something we could try to make editing posts/pages easier (note that the patch is far from complete so I've intentionally left it out of the repo). My thinking is that we can have an entire page dedicated to editing content (EditContentPage.xaml + .cs) rather than trying to squeeze that into the "edit post" and "edit page" screens.

If you load the patch up you'll see the following:

-the markup buttons have been removed from the "edit post" page
-the content of a post is now displayed in a scrollable text block element in the "edit post" page
-an "edit" button has been added below the scrollable "content" text block on the "edit post" page. Clicking the button will navigate to the new "edit content" page
-the "edit content" page contains a scrollable text box that contains the content of the selected post. An application bar with four buttons and two menu items is also displayed (as a placeholder) to demonstrate where we'd have the markup editing elements.

In the EditContent.xaml I've also left a context menu as a child of the text box so we could experiment with that, but I'm really liking the application bar (especially since the application bar buttons and menu items don't steal focus from the text box). Customization is pretty limited with the ApplicationBar and its controls but it seems like our best option.

The other challenge that I'm running into is that there doesn't appear to be a way to detect when the virtual keyboard opens/closes (see ​http://stackoverflow.com/questions/2757432/detect-that-the-onscreen-keyboard-has-been-displayed-on-windows-phone-7 for a good discussion of a similar issue). I'd like to adjust the height of the scroll viewer when this happens so we can still scroll around and see all of the text but that isn't looking like an option at this point. Maybe there are changes in Mango that will help resolve this, or maybe there's a way to detect some sort of transform/position change like in the list box that Jason found.

In [443], [444], and [445] i've added a new EditScreen by taking inspiration from one of the patches above. When you tap on the content box in EditPostPage, or in EditPagePage, a new page is shown on the screen with a full screen editor in it. The markup toolbar has now 2 rows, and it's always visible on the screen.

Further improvements:

We may need to add a contextual menu to the new screen.

Issues:

There is a limit on how much text we can display in a TextBox, since a WindowsPhone control cannot be larger than 2048px X 2048px. Even if you put it within a scroller it will be clipped at 2048px.