There are tons of questions I could maybe post this as an answer to, but before choosing the best one, I'll just post this as an announcement question that can be linked elsewhere.
The short story
From now on, intra-word emphasis is possible in our Markdown version. That means you can now write
The "V" is for Model**View**Controller. That's un*fricking*believable.
and it renders like this:
The "V" is for ModelViewController. That's unfrickingbelievable.
This only works for asterisks, not for underscores. It works in posts and comments.
The reasons
There are two big reasons for this. For one thing, this is more or less the behavior of CommonMark, which we eventually plan to adopt. "More or less" because CommonMark's emphasis behavior is still in flux, and supports a few things that we don't support yet, but at least with this change we're closer.
The other reason is languages that don't even have the concept of "words separated by spaces". See Has MarkdownSharp considered East Asian Scripts always have intra-word emphasis? and Issues with bolding for two examples. This change allow posts in those languages to emphasize words without having to resort to HTML tags. To use an example from the first linked post,
**北京**和**上海**是直辖市。
now renders like this:
北京和上海是直辖市。
Possible issues
In the 99% cases, this should only make things better; I've only found very few posts where this change causes unintended bolding/italicizing. And even in those cases, note that the rendered versions of questions and answers are not re-rendered until a post is edited, so this will not affect anything in posts retroactively.
Unlike posts, comments are rendered on-the-fly, so this immediately applies to all comments. In most cases this doesn't change anything or actually fixes things. Should you discover a rare case where this breaks an important comment badly, we can always edit it to fix.
There's one side effect that I'd like to mention: If you find a great quicksort implementation on GitHub that has a bug that causes a crash when sorting Windows versions, and the author doesn't want to fix it, you may be inclined to say
f**k this s**t
(i.e., "fork this sort"). With intraword emphasis, this would however look like this:
fk this st
So you would have to escape the asterisks (one of them would actually be enough). I'm not worried about this case too much, since if you must put censor-worthy words into a post, you might as well have to jump through a little hoop.
Some details
This being Meta, there are probably lots of people interested in a more detailed description of the new behavior (don't feel bad if you're not one of them; just skip this section).
Here are the major rules regarding intraword-emphasis:
As mentioned, it only applies to asterisks, not underscores. Underscores were the reason this restriction was in place at all; asterisks are much less of a problem.
If a single or double asterisk is supposed to be interpreted as intra-word emphasis, it cannot have punctuation on one side; it actually must be inside a word. An example of an edge case this solves is
It's a web*-based solution.
*see Wikipedia for a definition of "web"
where the asterisks after "web" could cause unintended italicizing if there was a second asterisk in the same paragraph somewhere.
For italics, the "inside a word" part of rule 2 is even a bit stricter. For bolding, any word or digit character is allowed; for italics, digits don't work either. That's because the asterisk is often used as a multiplication symbol, so
The game worked in 320200 and 640480 resolution.
wouldn't look right without this restriction.
A minor addition that I made that's only tangentially related to intra-word emphasis is that a sequence of more than three underscores or more than three asterisks will no longer take part in any emphasis. This shouldn't really cause any problems, but fixes some (e.g. the underline in the second blockquote in this post, while not really visible, is a weird combination of bold and italic underscore characters; after this change, it would just be (more) underscore characters). This behavior also matches CommonMark.