The first one is mentioned in [pd Dynamic-Patching], although it might be easier to understand if there is an example immediately under the text.
what do you mean by "immediately under the text"?
just a couple of objects under the paragraph where it explains
it. then it's more didactical - although the whole patch is full
of such examples, anyway.
The second isn't mentioned at all, the search results for "abstraction" and ".pd" return elements in other types of contexts.
You can see I also mentioned, in the same way as subpatches, that you can communicate with Pd patches, and I also have examples for that case so people could 'deduce' if I hadn't mentioned.
I guess I can be more clear that an abstraction is a Pd file, but that seemed obvious to me. I also didn't want to give an explicit example with an abstraction cause then I'd have to create yet another file. But this might be a good thing to call them both in th help file of namecanvas and this pd-message file.
I think you didn't understand - if you have an abstraction called
"abs1" used in the patch, sending messages to pd-abs1 won't work.
They need to be sent to pd-abs1.pd - and that could be clearly
named in the documentation.
But I also made it clear how [namecanvas] is useful for abstractions in its help file, that I emphatically tell people to check for reference. And I don't think it makes sense to talk to an abstraction using its filename, cause you can't just communicate with a single abstraction. I also don't know of a use case that from a parent patch you need to send messages to abstractions like that. Seems like the sane way to communicate with abstractions is via inlets.
I have an abstraction which is a midiroll-type of score with more than 35000 structs. As this is calculated dynamically when the main patch opens, so that I don't have to overload pd when programming. This is used only for the graphical display, so there are no other objects besides the structs. It is a quite peculiar situation,anyway.