Bad deployment scan order?

Steps to reproduce:

1) Download attached EARwithWAR-handmade.zip and unzip
2) Hot-deploy the contained directory - EARwithWAR-handmade
3) Check the deployment info (in EmbJopr) - a WAR contained inside appears
4) In the deploy dir, add '.ear' to the name of 'EARwithWAR-handmade' - rename to 'EARwithWAR-handmade.ear'
5) Now check the deployment info in EmbJopr. You will see:

• the WAR is DOWN
• new EAR appeared, but is also down
  6) After invoking the Start op on EAR, everything gets to the right state.

(18:14:46) ozizka: emuckenhuber: I've noticed one interesting thing. AS 5 deployment scanner first scans what's new and then what was removed. Shouldn't it be the opposite way?
(18:20:34) emuckenhuber: ozizka: well it first scans for removal and then for additions - where do you see that ?
(18:20:47) ozizka: I've tried it this way:
(18:21:18) ozizka: It scans recursively, so I've created an exploded ear directory, only without the .ear suffix.
(18:21:28) ozizka: So AS scanned, found the .war inside this dir,
(18:21:34) ozizka: and deployed it.
(18:21:49) ozizka: Then I renamed the directory - added the .ear suffix,
(18:22:01) ozizka: so what should happen IMO is first undeploying WAR,
(18:22:11) ozizka: and then deploying newly found exploded EAR
(18:22:24) ozizka: I know it's not usual use case
(18:22:45) ozizka: But instead, the WAR is reported to be DOWN (in EmbJopr)
(18:23:15) ozizka: and ear appears, but is DOWN too
(18:24:22) ozizka: When I invoke the Start operation on the ear, everything gets to normal, that is, EAR UP, standalone WAR disappears and Embedded WAR appears and is UP
18:25
(18:26:02) ozizka: emuckenhuber: And to add why I think that deployment is done first is this:
(18:26:02) ozizka: java.lang.IllegalStateException: jboss.web.deployment:war=/hellothere-inEAR is already installed.
(18:26:19) ozizka: that happens after the rename