Some of my manufacturing/SW experience will show through here. 
Every product has a bill of materials. These are built from subassemblies and further down, components. Component descriptions are written in a reverse, hierarchical order. For instance, you don’t say “1/4 Watt, 5% 37K Resistor”, or “1/4 Watt Resistor 37K 5%”, you say “Resistor, 37K, 1/4W, 5%” or something like that. The order of the hierarchy is not too important but is defined and static. That way you always know how/where to find stuff. And the most important attribute of said stuff is the easiest to find. Same concept holds in SW; think objects. Databases? Think data normalization.
In the above example, if you were looking to find all your resistors, it is a very difficult task, especially if the word resistor can be anywhere in the description. With a hierarchy, all your resistors, and even of a particular type, be it ohms, percentage or wattage, are grouped together with a simple sorted list.
So, specific to a curated suggestion list, I would categorize them by function, say “Reporting”, “Device Detection”, “Installation”, etc. If your system allows it, you could add sub categories, for example under Reporting, say “Mobile Device”, “Web” and “Data Feeds”. If a hierarchy is not supported, then you would use threads like “Reporting - Mobile”, Reporting - Web", and the like. As in the resistor example, consistency is key.
Each entry would be a succinct, clear reiteration of the suggestion; the official Sense restatement of what you understand the enhancement to be and/or do. If you read through the current suggestion category, you find may duplicates, but worded slightly differently, and under multiple threads, sometimes not understanding the underlying function of the Sense product. A single description would remove this confusion and make it clear what Sense is considering, and from the perspective/limitations/capabilities of the Sense secret sauce. You could also include any variations or possible extensions and/or Sense’s official position on the suggestion (maybe even timelines 
although that is always difficult, and now you have created yet another thing that has to be maintained).
I would point back to the original suggestion(s) that seeded the curated item for reference. You should consider locking the original suggestions once they are moved to the curated list (if not, you will have to continuously monitor items already moved). Lock and include a final entry pointing them to the curated item. (I saw the request/argument against the 4-day lock, so this may not be the best approach.) I would argue for an eventual lock, but not 4 days 
. If someone has a comment/modification on an item in the un-curated suggestion list and it is locked, they should first look at the curated item. Then, if they still have a cogent addition, starting a new thread would be best. This would then be picked up, and incorporated into an existing or new curated item. And the cycle repeats.