Things I wish I could change in JIRA

I've now setup JIRA to be used in 3 different companies and have I ever learned a lot.  In general, I really like it, but I can see how others can share different opinions.  I do enjoy how Atlasssian has been making some great improvements lately, especially around the "Project Overviews" and Git integrations.  They generally do a great job of walking a really fine line between being completely customizable (and utterly confusing, umm, I'm looking at you IBM Rational Team Concert) and being overly simplistic (Asana? Trello?).  With that said, there are a complaints that I find myself using ugly work arounds for or unfortunately just having to live with:

1. Email Notifications!  JIRA sure is good at sending out emails (or NOT).  Want to make one tiny little change to a non-critical field on an issue?  Sure, but that means the 6 other team members following that issue will all get an email.  Make a typo in that first update and want to fix it 10 seconds later?  That's okay, JIRA will send YET ANOTHER EMAIL.  Why not try something like this:

• Allow each user to tailor their own email preferences, instead of it being globally set
• Change the content in some email template to better allow users to setup their own inbox filters so they can see the emails they need to see and allow themselves to systematically exclude themselves from emails they don't.  Github does a good job here - I'm added in the "to" field if I'm tagged in a comment, but other emails I get (such as a new Pull Request that I'm not a reviewer) I'm BCC'd
• Just as users can decide to send an email or IM, let them decide whether or not the particular change they are making should or should not send an email.  Oddly, Atlasssian does this quite well in Confluence, just not JIRA
• Bundle up changes made within a few seconds of each other into just one email

2.  Backlog management.  I've tried a million strategies but everything always ends up with ugly work arounds that nobody else understands or can reasonably be expected to maintain.  There must be a better way to manage a product backlog.  The "Plan View" of sprint boards comes close, but what if you want to use a Kanban Board instead?  My current approach is to bastardize the use of "Sprints" in order to be able to find/plan/communicate what work is in progress, up next, or at the top of the backlog.  This is confusing, especially because in doing "planning" I inevitably end up sending a bunch of system generated emails out to users as I make changes, then reassess and update them a 2nd time.  

3. Searching for Children.  In the On-Demand version which doesn't allow plugins, it's impossible to find child items of an Epic based on particular attributes of that Epic (such as Status or Label).  I always find myself wanting to write queries that include searches like this, especially for Epics that cross multiple projects (such as a feature being added to both an Android and iOS app).