Thanks for the response Nagesh!
The though process primarlily relates to an auto-booking scenario where there is human intervention required such as the following:
A meeting room and a video conferencing device are both listed as seperate bookable resources in the Exchange GAL and enabled for AutoAccept booking. A designated contact (let's call her Sally) from the Audio Visual Department is responsible for ensuring that the video conferencing device is setup in the designated time and place.
Let's say I book a meeting for Wednesday afternoon from 2:00 - 4:00 and I invite both the devices. They are both available and autoaccept my request. On Wed morning Sally checks the schedule and sees that she needs to set up her device in room #403 at 2:00. She will be unaware of changes that might occur between when she first checks the Calendar in the morning and when the device is scheduled. The reason for the change could be that I have cancelled the meeting, changed the time, or maybe got bumped out of the room I wanted by someone with more authority and needed to change the location.
You could argue that the resource owner should have the resource Calendar open constantly but our users who manage the setup of these devices will only accept the autobooking functionality if we can provide this real-time notification when booking changes occur.
We have looked for ways to use rules to accomplish this functionality in conjunction with the AutoAccept scripts but since any "check messages after sending" rules are client-side only, we were not able to make this work seamlessly.
Hope this makes sense! BTW, all the functionality that is included with the 2003 scripts works great and I would highly recommend it for most implementations that don't have these more advanced requirements.