I need to specify any possible size, this becomes super critical stable layout on the page.
I guess what you are trying to determine here is if we could have a custom post processing job that injects size into the HTML and takes this decision away from the user.
My answer to this would be … maybe… If you upload retina you want to specify the smaller size so the retina screens get high fidelity and non-retina just get scaled down. It is possible we could glue this information into an EXIF tag or something and then have a post processor magic an SRCSET. But it would be a huge change.
line breaks between <img> tags
We absolutely need to deal with this cause we have tons of history, I can hack html_block.js to support this edge condition quite easily. But I also think the spec needs an adjustment here.
sepecifying custom image size
I also think the spec should deal with this, especially cause of the HiDPI concern.
So, i described the situation, but don’t like to take responsibility for your choice. IMHO, right now every choice is not ok. Because problem is on spec level, and i can’t push it forward. In nodeca, i decided to use alt content, but only to select between predefined sm|md|orig sizes, not to set WxH. Also, nodeca does not pretend to define de-facto standards.
About keeping breaks between <img> tags. IMHO it’s impossible to solve this problem easy on spec level. Because if you have a line with <img> tag only, it’s impossible to say, is it a raw block, or paragraph with raw inline element. I think, right now it’s better to hack html_block rule to filter out <img> tags - more easy to update in future.
Thanks heaps, totally understand, we are just stuck with no ideal solution here.
I really like this syntax proposal cause it is far simpler to parse and the Markdown looks much cleaner. Sure it is not as “flexible” as maruku like syntax but it is far prettier. I think we may migrate to it.
 Item One
[*] Item Two (should be checked)
[ ] Item Three
[*] Item Four (should also be checked)
Without escaping the * on one of the two items, it causes the text Item Two, Item Three to be rendered as italic and therefore the [*] doesn’t render as a checked checkbox, but rather 
If there was a way to force my rules to apply before <em> gets applied to *, it would solve my issue, as my rendered output would negate the parsing of * into <em>. But I’m not sure that is really advisable.
I’m 100% okay with going the escaping route, I’ll just drop backwards compatibility support as I don’t really have a lot of time to dig into why it isn’t working quite right without markdown-it enabled (feels like something magical and not a simple mistake on my part). Plus it would keep the plugin a bit cleaner and those who do not wish to upgrade (or can’t), can reference a tag to stay on their current version.
I’ve done that in the past, it hasn’t caused any major issues (to date).
On the other hand, I guess I could change the default behavior to mark checked with [x] instead of [*] and that would solve the issue without the need for escaping. I’d probably have to ask the users of the checklist-plugin about that sort of change though. (ping @meglio, @andrejkosyak, @steven, @downey, @Trash)
Then [*] would only be an issue for existing checklists and/or manually updating/creating them and the preview window would be indicative enough to hint you need to escape the *.
Without double checking the RFCs, my memory says that that sort of user and password was explicitly allowed for the ftp: scheme and explicitly not included in the http: and https: schemes. But people use it anyway.