Yes please, but with grep like filtering. 
I’d be very interested in SSL certificates with the embedded MQTT broker.
Yes please.
This one is huge. I can’t tell you how much time I and others spend on this one issue on the forum. I just spent 10 minutes helping someone with this very issue. The big deal is rules start running before Items are done being loaded and restoreOnStartup causing havoc.
I think David’s comment means that GUI based Rules editing is already in work. We don’t need to open new issues for stuff that is already being worked. I don’t think anyone is saying that the ERE is done and usable yet. As you mentioned, the documentation isn’t there yet.
The ERE will make this very easy FWIW. You can do this right now with just a few clicks.
NOTE: depending on what you are using these for, there might be other options. I documented a few in Design Pattern: Encoding and Accessing Values in Rules
The problem with this is Groups, despite how many people use them, are not strictly hierarchical and Items can belong to any number of Groups. I’m not sure using a Group name would work in this context.
Rules are event driven and are processed fifo. An event occurs and Rules configured to trigger based on those events. And no two events ever really occur at the same time. And unless there is something wrong with your Rules there should always be a thread available to start processing the event.
Given this is how it works today, how would you define the priority and what would you do in all the various cases? For example, I have a Rule that is already running at a lower priority, do I kill it if a Rule at a higher priority comes in?
I’m not arguing against the idea, just trying to understand how it fits.
Then one would argue you need to make sure the events occur in the order you want them to run. Short of a complete rewrite for how pretty much all of ESH/OH works I don’t see how priority can come into it. Maybe instead of fifo a priority queue could be used to assign a Rule thread to an event, but unless you have long running Rules, which is a problem unto itself, there should be no wait. No wait, no priority.
From an architectural purity perspective I agree with you. However, I have helped many users over the years with use cases that became somewhat needlessly complex because of this.
I think the sticky point is if one wants to display the lastUpdate on the sitemap there is a need to create separate Items and Rules to populate those Items. I’m personally kind of meh about the idea since it is so easy to solve with Design Pattern: Associated Items but I do understand the annoyance.
My list:
Generic Transformation Service
Can I expand nested transformations to pulling transformations out of the bindings entirely into a generic transformation service? Why is it I can only use a transformation with certain bindings (e.g. HTTP, Exec, MQTT, etc) but not others (e.g. Zwave, Zigbee, etc)? Why are the bindings involved at all? I’d like to see a way to link a Channel to an Item and apply a transform to the Channel at the Item, not on the Thing.
For a relatively trivial use case, let’s say I have a bunch of Contact door sensors. Contact is the appropriate Item type for this type of sensor. But all the Zwave door sensors require the use of a Switch. Now I either need to create a bunch of proxy Items and Rules to convert the Switches to Contacts so I can now use a Group:Contact for all of them or I have to deal with a Group:Switch and Group:Contact and duplicate the logic.
For another simple use case, I sometimes want to use a Number Item to store the result from an Exec script, but the output channel only lets me store the result in a String. Maybe a generic transformation service would let us write transformations that frees us to use the appropriate Item type for our home automation model instead of what the binding developers decided was appropriate.
Higher Default Number of Rules Execution Threads, Dynamically Sized Pools, Error Logs When Threads Are All in Use
I’m hesitant to request this as at best if masks a problem in people’s configurations. Five should be enough, but for some power users it seems not to be.
And 2 is definitely not enough for the Quartz thread pool. Especially with the natural human propensity to schedule events to happen at midnight or on the hour.
Very simple changes but I don’t know the overall implication.
Even better would be a pool that grows to some maximum and then starts logging errors when we get to the maximum.
At a minimum, it would be nice to get some logs stating that we have X rules awaiting an execution thread. Right now it kind of fails silently.
Sitemap Widgets for Filling out DateTime Items
It’s pretty self explanatory but one just needs to look at the massive complexity and pain involved in all the Alarm Clock examples to see how nice this would be.
It would be nice if it handled full DateTime as well as just a Time.
This may not fit with the core framework but it is a prerequisite for…
Dynamic Scheduler
Related to the previous, a built in scheduler. Lots of people go to great lengths to be able to dynamically set up a schedule for things to happen at certain times on certain days of the week on a repeating basis. For now all we can do is rely on something like the CalDav binding, which doesn’t work well for a lot of users or the creation of dozens of Items and complicated ugly sitemaps.
This is a major weakness in OH right now.
What people need is a way to say from their sitemap/HABPanel “Send MyItem the ON command every weekday at 8:30am” and create a Rule that triggers when MyItem receives the ON command. The Scheduler is smart enough to interpret the Item’s state and schedule the events accordingly.
Maybe this belongs in it’s own binding, but I’m pretty sure there is a need for at least one new Item type to make this work which does impact the core.
Add/Edit Tags in PaperUI
This one is a real challenge for less technical users who want to use Alexa/Google Assistant/Hue Emulation.
Elimination of Contact or Creation of A Standard that Gets Enforced
Contacts are supposed to be used for sensors, Switches are supposed to be used for actuators. But this convention has not been followed by the binding developers. In fact, rarely do I see Contact used at all. While there will be much wailing and gnashing of teeth, I’d like to see either the binding developers follow the standard convention or the elimination of Contact as an Item type.
Status Update on the ERE
This probably doesn’t deserve a an issue and may not even belong here, but what’s the status of the ERE? I know simple Rules can be set up but it is hard to judge it’s maturity. Can we access Actions (I know executeCommandLine is not available yet based on a recent thread)? Logging? Timers?
I’m willing to take a shot at starting the documentation for it but don’t want to start unless it is nearing completeness.
I’m sure I’ll think of more in the shower tomorrow morning. 
Improve Performance of Rules DSL Parsing
There might not be much that can be done with this but users are reporting start up times of 10-40 minutes on RPi 3s due to Rules parsing. I suspect the main focus is on the ERE right now, but the Rules DSL will be around for a bit and we shouldn’t ignore this pain point.
And perhaps I misled by saying ‘enduser’, and by that I meant someone like myself who is not a developer, but runs their own OH2 system at home and is familiar with the setup, installing from scratch on a linux or other OS machine, setting up mosquitto, etc.