I have already noted the new loved properties for tracks and playlists. I must admit that an update to the iTunes sdef was heartening (pun not much intended). However, there are some lingering issues and new issues with the latest incarnation of iTunes. Perhaps they have yet to be got to. Yeah, that's it. They'll fix it, fingers crossed.
Pretty much anything to do with the Apple Music tabs is off limits to AppleScript. So, for example, you can't select a track or playlist in "For You" and get info about it or manipulate it. I don't mind this so much. Once tracks are added to "My Music", they are accessible as shared tracks. It'd been the same with iTunes Match tracks. You can get and set the conventional track properties, you just can't access file metadata because, by definition, there are no local files for tracks in the cloud. Still, access to tracks and playlists in "For You" and "New" might be convenient, if even for accessibility purposes.
I am disappointed that current track does not work with playing Apple Music tracks (if playing from within the "For You" tab). I'm not sure if there's a security issue here, or it's just not hooked up yet. Definetly screws up anything watching for current track to change. Notifications is aware of playing Apple Music tracks, so why not AppleScript? Even as read-only. I'd be cool with that.
The new Playlist view doesn't seem quite hooked-up yet either. This is the new default view for local playlists. Anyone who's ever worked with broadcast automation will note that the abridged track information in Playlist view is reminiscent of a music log. (Note to Apple: please let us change this default view. As much as I really like the Playlist view I prefer Songs view as default to work with track tagging and only switch to Playlist view on formal occasions.) AppleScript-wise, it's all OK. But the reason I don't think it's hooked-up properly yet is by observing the pasteboard data from a playlist in Playlist view. Now, pasteboard data for dragged tracks and playlists typically contain metadata about the playlist and tracks being dragged. Except when the drag originates from a local playlist in Playlist view. In such cases, only the file paths are available in the pasteboard. And if cloud tracks are included in the drag, well, they don't have local files, so nothing about them at all appears in the pasteboard. However, when the very same playlist is in Songs view, the metadata is available from the dragged tracks' pasteboard as expected. So the data is already permissibly available, just not (yet?) in Playlist view. I suspect that, because it seems to be the same view used in "For You" when you play a playlist there, it has no provision for includiing metadata. Someone should get on that.
Also, there's no AppleScript way to access the artwork(s) or description that is a part of the new playlist header. It would be convenient to be able to script a playlist's description at least.
Many of my scripts and apps access the iTunes Library.xml file to get information about tracks and playlists. That's what it's there for. iTunes 12.2 has, uhm, mucked around with the format of this file. As a result, there's been a big scramble by all of us who develop iTunes apps to re-jigger our stuff. The XML now contains information about mobile apps, Ringtones, iTunes LP, iTunes Extras, and books. The "Master" playlist has a name of "####!####" where it used to be "Library". "Smart Info" and "Smart Criteria" keys are now being used with playlists other than the Smart variety. Additionally, there is now no way to tell the difference between Genius and Smart playlists; they look identical in the XML. Previously, a Genius playlist would key the persistent ID of its seed track and this would be a differentiating factor. But the "Genius Track ID" key is gone.
The new "Share iTunes Library XML with other applications" Preference setting is still a mystery to me, but I suppose there could be situations whereby you'd want this off. Sometimes I'm just plain dumb about things like that. But because some users think it looks like the perfect thing to uncheck I've needed to include a check for access to the XML at the start of many apps. Because if it's off, the script or app won't work.
On the bright-side though, despite the Apple Music considerations, iTunes still has pretty robust AppleScript support! So thanks for that, Apple.