At present, as far as it has got at v9.2.0 is the document() dictionary object has a
A related lower-level issue still being resolved is how the Dictionary type gets/sets multi-term values (i.e. lists), such as the the list of currently defined link types.
Also since v9.1.0 eachLink() allows action code access to all the current objects links. I thin one is essentially looking at each link and a sub-set of the underlying XML <link> data object. The value of the type key is that link’s link type. I’m not sure (i.e. not explicitly tested if any of the key values are read/write or read-only). Why not give it a try.
However, there is no action code to directly address link types, either as a doc-level per-link-type set of defaults or as customised at per link level. I can see that’s a lot of code for a niche use so it might help assess the ROI (cost/value) if you could unpack your use case a bit more.
Also, I’ve checked the current (v9.2.0) AppleScript app dictionary (i.e. allowed terms/usage) and link types are not exposed beyond the name of a link’s current link type.
To ‘just’ set up a doc for another user, it is still easier to make a new doc and customise it. Or another approach to the same end, take a customised doc, and strip out all the data (the ‘content’ as it were) leaving all the prototypes, stamps, templates, composites, custom link types, etc.
Note although user attributes have a ‘Description’ that is saved as part of the attribute’s data, link types don’t. I suspect is that is because most users employ link type names as screen labels of box-and-line type visualisation. As one moves to using links less for their visual element but as a means to compute across the graph of connected notes, it might be useful if link types also allowed for a description of the types purpose. Indeed, a link might not want or need a map-visible label, but we still might want to know what type ‘X’ is for and how it is different from type ‘X2’.
Of all this issues here, the one offering most traction towards the aim seems to be getting dictionary type objects to be able to get/set list values as well as single values, which also implies being able to address discrete values in a list value without laboriously (for the user’s code at least) literally iterating every value in case it is a list vale to then identify and work on the one intended. I believe this is work in progress at present. That’s good as fixing that action code aspect also fixes/enhances a lot of other action code use.