We'll try to get to this for GNOME 2.24.0.  Thanks for reporting this bug!

Created attachment 113141 [details]
Orca debug log generated whilst testing this problem.

I tried the following:

* Started Orca
* Started Thunderbird
* Tabbed to my list of mail folders and selected the Trash folder.
* Tabbed to the mail header list for that folder, arrowed down
  and pressed Delete to delete a mail message.
* Repeated step 4 a couple more times.

Looking at just the last deletion (keypress on line 3322), we
see the following events are queued:

---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT focus:
---------> QUEUEING EVENT object:state-changed:focused
---------> QUEUEING EVENT object:state-changed:busy
---------> QUEUEING EVENT object:text-changed:delete
---------> QUEUEING EVENT object:text-caret-moved
---------> QUEUEING EVENT object:text-changed:insert
---------> QUEUEING EVENT object:property-change:accessible-value
---------> QUEUEING EVENT object:children-changed:add:system
---------> QUEUEING EVENT object:children-changed:add:system
---------> QUEUEING EVENT object:text-changed:delete:system
---------> QUEUEING EVENT object:text-changed:delete:system
---------> QUEUEING EVENT object:text-changed:insert:system
---------> QUEUEING EVENT object:text-changed:insert:system
---------> QUEUEING EVENT object:property-change:accessible-value
---------> QUEUEING EVENT object:children-changed:add:system
---------> QUEUEING EVENT object:children-changed:add:system
---------> QUEUEING EVENT object:property-change:accessible-value
---------> QUEUEING EVENT object:property-change:accessible-value
---------> QUEUEING EVENT object:property-change:accessible-value
---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT document:load-complete
---------> QUEUEING EVENT object:text-changed:insert:system
---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT object:children-changed:add:system
---------> QUEUEING EVENT object:children-changed:add:system
---------> QUEUEING EVENT object:text-changed:insert:system
---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT object:children-changed:add:system
---------> QUEUEING EVENT object:children-changed:add:system
---------> QUEUEING EVENT object:text-changed:insert:system
---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT object:children-changed:add:system
---------> QUEUEING EVENT object:children-changed:add:system

That's a lot of events!

Looking at the "focus:" event, (because that's the one I would expect to
speak the new mail header list item that now has focus), we have:

vvvvv PROCESS OBJECT EVENT focus: vvvvv
OBJECT EVENT: focus:                                   detail=(0,0)
    app.name='Thunderbird' name='11:19 AM' role='table cell' state='enabled focusable focused opaque selectable selected sensitive showing vertical visible' relations=''
---------> QUEUEING EVENT object:state-changed:busy
Finding top-level object for source.name=11:19 AM
--> obj.name=
--> obj.name=
--> obj.name=
--> obj.name=Trash - Work Account - Mozilla Thunderbird
LOCUS OF FOCUS: app='Thunderbird' name='' role='table cell'
                event='focus:'
^^^^^ PROCESS OBJECT EVENT focus: ^^^^^

When you delete a mail message from the middle of the message header
list, the one that then gets focus, will be on the same row as the previous
one you just deleted.

I added some debug to the locusOfFocusChanged() method in the Gecko/script.py
file, and found that it was just returning (at line 2593) with:

        # Sometimes we get different accessibles for the same object.
        #
        if self.isSameObject(oldLocusOfFocus, newLocusOfFocus):
            return

That's why we don't speak anything. This is also why when you delete 
the last message in the folder, it's spoken. The row number has changed.

In the Evolution script, there is a whole chunk of code in its
locusOfFocusChanged method [section 3) - lines 684 to 940] that are
there specifically to handle this situation:

There's code like:

            # This is an indication of whether we should speak all the table
            # cells (the user has moved focus up or down the list, or just
            # deleted a message), or just the current one (focus has moved
            # left or right in the same row). If we at the start or the end
            # of the message header list and the row and column haven't
            # changed, then speak all the table cells.
            #
            justDeleted = False
            if isinstance(orca_state.lastInputEvent,
                          input_event.KeyboardEvent):
                string = orca_state.lastNonModifierKeyEvent.event_string
                if string == "Delete":
                    justDeleted = True

            speakAll = (self.lastMessageRow != row) or \
                       ((row == 0 or row == parentTable.nRows-1) and \
                        self.lastMessageColumn == column) or \
                       justDeleted

It looks like we now need to add a similar chunk of code to the Thunderbird
script as well.

Created attachment 113286 [details] [review]
Revision #1.

A lot simpler that the Evolution equivalent, as we don't have to
work around an Evolution event bousity, but can use the default
(or rather Gecko toolkit) table cell handling code.

This works nicely if you are deleting from the message list bug does not give any feedback if you delete from an open message.  
To reproduce: 
1.  Have an inbox with 5 messages
2.  open message 3 by pressing enter
3.  press delete to delete the message.  
Notice that you hear nothing and the braille display does not change when the next message opens and gains focus.  

As Mike indicates, it works well when focus is in the message list.  However, Thunderbird crashes when I try to repeat Mike's steps of deleting an open message. I'll get a new and clean version of Thunderbird sometime soon and see if these crashes go away.  I'll keep you posted.

Thanks Mike/David.

There is another bug I'm looking at, at the moment, but I'll 
get back to this one as soon as I can. 

Created attachment 113338 [details]
Orca debug log generated whilst testing the problem in comment #5

When testing Mike's steps in comment #5, I get Thunderbird to crash.
I'm using:

$ ./thunderbird --version
 Thunderbird 3.0a2pre, Copyright (c) 1998-2008 mozilla.org

This was a tarball I downloaded. If it still crashes with
latest Thunderbird from their source repository, then I'll
file a bug against it, create a new Orca bug, and block it.
That will allow us to work towards closing this one (which I
think you will agree is separate -- and fixed).

F.y.i.

I just did the Thunderbird automatic update, and I'm now at:

version 3.0a2pre (2008061103)

And I still get the crash.

I've moved the bug found in comment #5 out into 
a separate bug (see bug #539975). 

I've committed the patch attached to this one,
and have moved the bug to "[pending]".