A near-future release of IPS4 will include a major update of the editor. We'll need to re-evaluate at that point whether clients are happy with the mobile editor experience at that point. Significant improvement is expected in the CKE update.
Nothing is ever that simple. That's going to lead to support which is going to end with IPS assuming liability for what you use the functionality for without understanding the ramifications. Put simply, in a stock state, there shouldn't be anything for IPS4 to do here (but again, you should consult with a professional legal expert in your local jurisdiction.) We're not willing to get involved in EU regulations, I am sorry... and this is not an unusual position for a software developer to take on the "cookie law" and I'm not aware of a single one that offers out of the box compliance assumptions -- if they do, they're likely based in the EU -- we're not. Sorry we can't be of more assistance on this. We're not open to further feedback on this position at this time.
Our position, like every other similar software developer that has no control over end-use, unfortunately has not and will likely not change.
The interpretation there implies what I've personally felt all along - unless you're doing advertising/tracking, you may not even need to get into cookie consent anyway. If you are doing advertising, tracking or collecting personal data, it's up to you to seek legal advice (as noted in the first paragraph above) as to how the law may apply to your particular situation. You may need consent, you may need more. We at IPS don't know and we're not willing to guess on a one-size fits all basis and instill a false sense of security for compliance and subsequently subject ourselves to liability for potentially being wrong when someone goes hog wild with advertising and tracking and violates their local laws while thinking IPS has them covered. You'll note Google itself has not provided any direct solutions and are very careful not to provide specific direction, they merely point you to other resources and note you should get legal advice. That is, has always been and will remain IPS' position as well, I'm afraid. If we had a uniform solution that didn't contain the ability to be modified and used in different ways, yes - we'd absolutely consider making an easy cookie consent feature built-in. Because the software allows, but cannot account for third party modifications that can seriously impact your compliance with such local regulations (for example: if you add advertising, you may only need cookie consent -- if you do detailed tracking, you may need to document cookies) - we're not willing to entertain this on a software level. As noted above, there is a modification in the marketplace (free) that will easily provide cookie consent (if you determine that's all you need.) I'm really sorry guys, but there's not much we can/are willing to do here.
Toggle what? Replies to status updates altogether? I don't believe we've considered that one way or another yet. This is kind of why we don't just "do stuff" though. From the user end, you want a quick reply to status updates. From our end, it doesn't work like that. To do formatting, we'd have to do the RTE, which then means we'd have to load it in a modal / popup and at that point, it's just silly - go to the full status page as it's no longer all that quick, right? We'd then get "can't you just put a text box there? Then, we can easily do unformatted quick replies, but then you run into endless requests like "can you do unformatted + emoticons + hyperlinks + in-line attachments + <kitchen sink>?" Which brings you back full circle to formatting. Then, invariably and understandably -- "ew, can I shut that off?" You can understand why I'm bald! When we get closer, it will go through the vetting process where we'll try to cover all the angles and find the best approach to fit the most people.
We've not yet committed to the best approach to implement this, but it will likely just be a text field -- i.e.: unformatted reply. If you wanted to go all out with RTE, you'd go to the full status page. There's no immediate ETA that we'd be prepared to commit to, but it is in our sights.
For the first part, I'd almost call that a bug - we can look into that. For the second part, what's an example use-case for BCCing PMs? Why wouldn't you use the bulk mailer at that point instead of creating 200 conversations? Flag them as a spammer. I did say we'd look into pruning options.
You and the polls. We don't do anything based on polls, for what it's worth. The software isn't vote-driven and as ~5% of the userbase even visit, much less participate in the community, it's not a very good sampling. That said, on public communities (including this one), I don't do e-mail notifications. On our internal stuff, I do and I actually like e-mail per reply - it's handy when on the go and glancing through e-mail trying to catch anything important vs a one-off notification requiring you to visit the site. The setting referenced in vB was introduced at a time when when e-mail clients didn't support threaded discussions (based on your screenshot, it appears yours still doesn't, so maybe that's the crux of your issue. ) I don't think we're necessarily opposed to adding a setting to allow this and we'll give this consideration - but I'm not sure the demand value (scientific poll notwithstanding) is there. Daily and weekly digests are already an option as is disabling e-mail altogether.
So, make an internal policy to hide posts - then you can go back and delete them after you're really sure that's your intention, or restore them if it wasn't. Adding this to the software is redundant - I do get mistakes happen (1 time in 11yrs isn't a bad track record though!) but don't click delete if you're not quite sure - use hide.