The broker does not store the noLocal value as part of the SubscriptionInfo object that represents stored durable subscriptions. This means that on restart the value for previous subscriptions is not recovered from the store which means we can fail tests for this bit in the JMS spec:
If an unshared durable subscription already exists with the same name and client identifier but a different topic, message selector or noLocal value has been specified, and there is no consumer already active (i.e. not closed) on the durable subscription then this is equivalent to unsubscribing (deleting) the old one and creating a new one.
This also means that an AMQP receiver that tries to recover a previous durable subscription won't be able to validate the remote Source to validate that its state matches the requested subscription configuration.