This is actually two questions rolled into one:
(1) Association inherits Relationship. For classes which inherit DirectedRelationship, the convention seems to be that the specialized DirectedRelationship class is owned by its source Element, although I could not find an explicit reference to that.
For Association, I cannot find anywhere in the specification that explicitly says what the type of the owner Element should be. However, it is stated that there must be an owner because only Packages are allowed to have no owner.
It makes the most sense to me that the owner of an Association should be the nearest enclosing Namespace of all of its related Elements, which would also apply to N-ary Associations. Is this also more or less the consensus among UML tool implementations?
(2) An Association can also be derived -- on p. 242 in the last paragraph before section 11.5.3.2 "Association Classes" begins, it says:
"The existence of an association may be derived from other information
in the model. The logical relationship between the derivation of an
Association and the derivation of its ends is model-specific."
Does this mean that an Association does not have to exist in the model? If I want to generate an XMI file from a model, wouldn't I have to explicity include all Associations? I am wondering about the case where a Class can have an attribute referring to another Class which could also be represented by an Association (or Dependency), but the modeler chose to model it as an attribute ... is this what is meant by that paragraph?
Associations are PackageableElements. Therefore, they can be moved around as you like. The owner of an Association has no bearing on the meaning of it. Some tools even hide the owner.
The convention to place it in the nearest enclosing namespace can make sense. However, if one end of the association is more abstract than the other, I would place it in the namespace of the more concrete element. For example the Association between Actors and Use Cases should be in the same package as the Use Cases.
Derived Associations are still Associations. You need a place to define that they are derived. So, they would be in the XMI. Only in an object diagram the links, defined by this Association can be generated by the derivation rule and would not be in the XMI.
The last point you mention is the association like notation. It just borrows the notation from an Association. I think, it makes sense, since an attribute in fact links two instances of classes, just like an Association. The only thing that is missing from a complete Association is the opposite end. Maybe, you don't need the opposite end. Why should you then be deprived of a graphical notation for the relationship?