The contents of the "description" and "mt_text_more" should be whitespace-trimmed in order to make the behavior for entries submitted via XMLRPC match the behavior for posts entered manually in the wp-admin editor.
Specifically, xmlrpc.php currently joins the literal values, including any whitespace, by a literal "\n<!--more-->\n" constant.
The intent here is to prepare the text such that it perfectly mimics the format that code in wp-includes expects when parsing the content of a post and splitting it back out into teaser and extended. But by retaining any whitespace from the submission, it screws things up in a number of ways:
1. The trailing newline that a user might naturally type at the end of a "teaser" composition is retained, thus causing a double-newline in the content of the post which is permanently stored in the post, and shows up in rendering.
2. Because the assumptions about the teaser and extended being white-space stripped are so high, the XMLRPC methods for returning the content *do* strip the whitespace, so clients are given an unrealistic view of what the post actually contains. While the post will have ended up with a trailing newline in the teaser, and will render with a <br />, the XMLRPC client continues to be under the illusion that the whitespace had been trimmed.
By actually making the XMLRPC methods trim the whitespace on the way into the database, it seems to solve the problem at the root. It's possible that in the future it would be a nice ambition to preserve literally whatever whitespace a user submits for these fields, but at the moment the expectations for stripped components is so high, the guarantee should be encouraged here for maximum compatibility.
I've attached a patch which at least crudely fixes the problem. There's an issue of code repetition that I didn't attempt to remedy.
