1. A suggestion: change the download name to include some form of versioning with each new release. I wanted to keep the version 2.2 distributable but the same name download caused Debian to add "(copy 1)" to the new download filename and I had to be careful about which I used.
The binary package download link downloads only the latest stable release and rarely some critical bug fixes. If you need to get the latest changes, better clone the source repository and update locally. This way you will always get the recent version of the source. Also, you can download the recent commits from the web page of the repository.
2. The non-image text for the inline code button is "Mono". Not sure how that was derived, perhaps with reference to the Mono font that is fixed width, but "Inline" or "Embed" might be better choices.
Although this formatting is often used for inline code, it is actually simply formatted with a mono-spaced font. From here is the name "Mono" on the button.
On the other hand, the code block is especially designed for handling source code. For example it is possible to make it with syntax highlighting for different languages.
3. I suppose the emoticons are important to some readers/writers but they occupy most of the format button line where other formatting capabilities might be added, such as heading choices, indented text, and lists (both numbered and non-numbered).
The emoticons are pretty counter-intuitive for use. That is why I put the buttons there. Maybe they can be made as a pull-down menu or something.
4. The edit post window is an interesting way of handling this function but it is inconsistent with the add new post function. Is there a special reason for doing so?
The difference is because when writing new post, the user usually writes big amount of text and checks the preview rarely. While, when editing, the text changes are usually relatively small, but the user checks the preview more frequently. At least I am behaving this way.
Notice that this difference is only for the desktop skins - "Wasp" and "Light". The mobile devices skins have more simple editor, because of the smaller screen area.
5. The edit post window hides the text in the right side of the original post even though it becomes transparent when the mouse is moved out of the edit window.
The editor window can be moved by dragging the header. If you want to check in details the right side of the text you can move it to the left.
6. The edit post window starts at a fixed size, allows for width and height adjustment using the tag in the bottom right corner, but loses the changed size when the preview button is clicked.
The same problem have the SQLite console though. But I simply don't have ideas how to implement a persistent sizes.
Notice, that I am pretty low skilled front-end developer and even worse designer. While changing the back-end is easy and quick, changing of the skins html/css/js costs me huge effort and the evolution of the skins goes very slow.
But the project accepts contributions. If you have reasonable suggestions, simply make them as code and they will be merged to the repository.