Das wäre meine nächste Frage gewesen. Eigentlich müsste es bei TextEdit auch passieren, da diese App auch NSDocument-basiert ist und in der Sandbox läuft.

Ich habe auch Espresso und Coda (und viele weitere Editoren) auf meinem Rechner, aber habe das Problem nicht. Leider gehen mir die Ideen aus, an was es liegen könnte :(

Textastic uses the value "Owner" for the "LSHandlerRank" key for HTML documents in its info.plist.

I assume that launch services randomly chooses one of the "Owner" apps for each file type to be the default app.

But, Safari has the key "LSIsAppleDefaultForType" set to true which should probably rank higher.

This is what the docs say:

LSHandlerRank: Determines how Launch Services ranks this app among the apps that declare themselves editors or viewers of files of this type. The possible values are: Owner (this app is the creator of files of this type), Alternate (this app is a secondary viewer of files of this type), None (this app must never be used to open files of this type, but it accepts drops of files of this type), Default (default; this app doesn’t accept drops of files of this type). Launch Services uses the value ofLSHandlerRank to determine the app to use to open files of this type. The order of precedence is: Owner, Alternate, None.

Since Textastic is a creator of html files, I chose "Owner" and not "Alternate".

I guess changing it to "Alternate" would leave Safari the default in all cases.

So Mac OS X automatically chose Textastic as the default and you didn't select it in the "Get Info" dialog in Finder?

It doesn't do that on my machines - Safari is still the default. I'd have to explicitly tell the OS to use Textastic "to open all documents like this one".

Is this on Mountain Lion?

I just found this topic in a WriteRoom Google group which mentions the same "could not get a sandbox extension" error: https://groups.google.com/forum/#!msg/writeroomapp/GqBs6X1d8g0/EVhJZBgy1CcJ

This post is interesting:

If you open Console.app, do you an error containing this message when you try to save?

" -[NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. "

If so, then the OS X sandbox is preventing WR from using that extension to save to and has decided that only *.txt or whatever will do. I'm not seeing *.md or *.mmd getting renamed on my end, but I'm having that problem with other extensions like *.org. 

It might be because I have several other Markdown editors installed, which is placating the sandbox regarding those extensions. Or something. In 10.8 there's a reference to a "related items" feature, but I actually am unable to find the documentation for it at all beyond a message from an Apple employee in October 2012 saying they were still working on the documentation for it.
That doesn't solve your problem, and I'm sorry about that as well as how long it took to get a reply up. 

I highlighted the interesting part. It sounds logical that another app might have messed up something in regards to file extensions that is preventing the sandboxing feature of the OS to change the file extension.

Thanks a lot for the screencast!

I have done exactly the same as you did in the video. I even disabled iCloud because it didn't appear as an option in your save panel so you seem to have it disabled. 

I have typed the same characters and used the same menu items, but it works just fine on my iMac and on my Macbook Pro.

Could you try to use "Repair permissions" in Disk Utility? Maybe there is indeed a permission problem somewhere on your hard disk.

I don't know if that's too much to ask, but: if you would be able to record the problem in a short screencast, that would be terrific!