This ist absolute essential if someone will use SMS for alerting.
If I understand correctly, then I fully support.
For example, you can create a third type of trigger (Event generation) such as "Normal + Multiple PROBLEM events limited N times in M seconds"
N, M - is new configurable option for trigger.
And N - this is not the count of switching trigger OFF to ON, and is the count of PROBLEM events.
It will be very useful for processing eventlogs where you can not miss a few consecutive's errors, but if started a storm of errors, you need to limit the count of alerting.
This would be a great addition. I do use notification delay on actions, but many times a lot of SMS's are being send. For me, a notification like 'There are X more problems on {HOSTNAME}, I'll stop spamming now...' would be great too.
Any plans for implementing these features?
As commented in the forum[1]: maybe the escalation system could provide tools to solve this?
[1] http://www.zabbix.com/forum/showthread.php?p=83009&posted=1#post83009
I don't think escalation helps much here. At least without having to introduce innecessary additional complexity in the configuration, like fake dependent triggers etc. Both flapping detection (you get notified immediately as soon as a host is unreachable, but then you don't get extra messages if the host keps getting on/off for a while) and limit on the number of notifications (person X doesn't get more than N messages per ... hour/day/... perhaps just digest emails from that point on)
would be great!
I also looked at the escalation options for mitigating this problem, but if i understand that correctly if you use it that way you can't then profit from the real purpose of "escalation", it's then 'either or'.
Escalation case as i understand or like to use it: a host gets down and Zabbix notifies the admin immediately. If after a day (say) the host is still down, the admin should get another notification. Then extra notifications the days after, or perhaps just after 1 week, 2 weeks etc.
Delayed notification to avoid reporting on short (network) interruptions: in this case you need to set the action base period to few minutes, and set the Operation to happen from step 2, for instance. But then you can't use escalation as above... becaus then you'd need to get mails every few minues.
I vote for a personal, per media (i.e. configured in user's profile) limit on the number of notifications. (SMS notifications will be blocked per <3600> seconds if more than <20> SMS notifications has been sent to the user in last <900> seconds. An informational 'notification media blocked per <3600> seconds' message should be sent to the user.
I like Pavel's idea. Often servers go down, and I get 100 different messages, all perhaps the same thing (e.g. zabbix agent down). After the first message, I am already aware there is an issue, I don't need another 100 different messages pointing to the same thing. So a restriction of the # of notifications per media type would be great.
Is there any plan to implement a solution for this issue in next releases?
I assume if there are any plans the Zabbix ID would be set to "Next Major Release" instead of "Ready To Discuss".
Vote for it! 
ZBXNEXT-2670 is similar (asks limits for user media level).
I many cases using dependencies helps, but on several occasions i got thousands of "agent is unreachable" alerts when queue got too large for whatever reason.