Short answer to topic title: NO
Below the longer version:
The specification says “AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame”.
You write “In this case: unique per application” which is an understandable but incorrect assumption.
The specification explicitly says the entity able to process the JoinReq frame and not application.
The specification also says “the entity” and this is where I think the specification is not precise enough because (based on current implementation) this probably should read “an entity”.In which case multiple applications can serve as an ‘the entity able to process the JoinReq frame’.
Off-the-shelf devices must be able to be used right out of the box without having a user to configure any keys on the device first. To make this possible they must be pre-configured with DeviceEUI, AppKey and AppEUI (all three of them).
DeviceEUI and AppKey are end device specific (properties of the end device).
AppEUI is a property of an entity/application that can handle the join request for this device, but only if the end device is registered for that application and an end device can only be registered to a single application.
From the perspective that a(n off-the-shelf) device must be able to be registered to any application (but only one at a time) it makes sense that any application can be enabled to handle a join request of that device by adding the AppEUI (configured in the device) to that application.
The device must be registered for an application to be able to join, but technically this does not require the AppEUI to be unique for that application and hence an AppEUI can be shared by different applications (possibly even by applications from different accounts).
Giving each device their own unique AppEUI as some suggest would not be useful and not be logical. The device is already uniquely identified by its DevEUI. The devices of an application can all share the same AppEUI (unless they come hard/pre-configured with different AppEUI’s). This is exactly the same as when an application only has a single (its default) AppEUI which is then automatically used during device registration (when the user does not explicitly enter an AppEUI) and the user then configures that AppEUI on the end device(s).
Why do you mention MIC here? Did you mean DevEUI and AppKey instead?
In which case only DevEUI and AppKey would have to be specified when registering a device, without needing to bind it to an AppEUI (that must have been added to the application in advance)?
“why did the LoRaWAN specifications even bother about defining the AppEUI?”
Maybe @johan knows the answer to this?
Possibly with future extensions in mind (e.g. Join Server like)?
Or maybe speedup the handling of join requests?
Can it be related to that NetworkSKey and AppSkey are not yet known during the join request?
The application name appears to be the primary key of applications.
This explains why two different user accounts cannot use identical application names.
It also explains why applications can share AppEUI’s, because it is not their primary key.
The name AppEUI which is usually referred to as ‘Application ID’ gives a wrong impression and puts us on the wrong foot because AppEUI is not the unique primary key of an application.
This is probably (one of) the reason(s) why it was renamed to JoinEUI in later versions of the spec.
(In database design it’s bad practice to use name as primary key. This is probably a V2 design flaw).