That can happen (to wsdl2jave, in particular, or possibly to whatever code-generation tools) usually if your local element(s) is in some namespace(s) other than the global element containing it and that, in consequence, your xsd contains also xs:import element for instance... The code-generation engine may thereby consider annotating the package with QUALIFIED be more convenient in those cases...
But, at the end, the apparent non-honouring of elementFormDefault in the package-info should not be a cause of failure of validating or unmarshalling the xml that is constructed with xsd as its blueprint. What I mean is also that you have to, if in doubt, first of all, validate the xml from within the xml-xsd line as the
test before looking into what might be wrong in the data binding. Also looking from xml-xsd-centric angle, the elementFormDefault unqualified in the xsd can always be rewritten in an equivalent form with an xsd combination all with elementFormDefault scripted as qualified instead.