I can't edit the styles used in a drawing based on a linked read-only gpx file. I get the can't add record error message that I have attached previously. I think that this is a bug.
Sigh... I'm not exactly sure how many times I can write the same thing in different words if you ignore what I write. I repeat for... what?... the fourth time?... You cannot modify a read-only data source. That is not a bug, it is a critically important function of the software. When someone declares a data source read-only he or she must have 100% assurance it will not be modified in any way. I hope you can see the wisdom and the non-negotiable necessity in that.
Now, that you can store styling information within the data source or within the project also is not a bug. That is a feature of great power, but like many features of great power it will apply, with great power, exactly what you tell it to do. If you tell it to do something that's contrary to something else you told it to do, it will complain.
For example, saving styling information means adding a record. I trust that given your interest in styling you've already carefully reviewed the example topics on manipulating the mfd_meta table and that you've watched the video on that, right? By doing that, you know that styling is saved in records in a table, like everything else, and also by reading those topics and watching the videos you have learned what a tremendously powerful and useful thing it is that styling properties are saved in tables. It's just fantastically useful, not something to throw away.
So, since you know such stuff is saved in tables, why the surprise that when you try to save it in a table in a read-only data source the software tells you that it cannot create a record?
Before we talk error messages, consider that Manifold lets you work with about 500 formats and data sources. It does indeed come to that when you count all the formats and all the data sources and then multiply by the very many variations some of them have. Many of those are highly sophisticated data sources that provide zillions of options.
Back to the error message: If Manifold was a smartphone app that did just one, itty-bitty thing, then of course it would be possible to provide a very simple error message. But given that when you try to modify a data source there are many ways you can instruct the system to do something contrary to what you have previously instructed it to do, it gets much more complicated to report that you've done something wrong without telling a lie. You want a helpful error message? Me too and everybody else, so we all agree with you. Helpful error messages almost always require telling the truth.
In this case, there are many reasons why you might not be able to modify a data source *other* than it being read-only. For example, the data source might be perfectly read-write for other people but not for you, or it might be read-write for certain fields but not some fields, or it might be perfectly read-write for existing fields but not allow modification of the schema to add new fields, etc, etc. Those are all legitimate things that people who administer data routinely want to apply. So there is no, one-size fits all, "Sorry, can't modify a read-only source" error message. The least common denominator is to report what actually failed "can't add record" and leave it at that.
Now, you may think "Oh, I don't want to use any of those sophisticated things, I just want to do this one thing and I want an error message crafted for me specifically in this case." I wrote that as if the request is daft, but, really, it is not daft at all. It's a perfectly fair request, and one thing that gets software a reputation for, despite technical sophistication, being easy to use is the accumulation of thousands and thousands of such small things. So sure, Engineering could step right in and write special code that examined data coming in from linked read-only GPX files, consider the various classes of things people might do with such files and then write a series of special case error messages to pop up. The only question is how happy all the other users would be about the application of such effort instead of the same amount of engineering time being spent on matters of broader interest.
For example, I would recommend not altering such error messages but instead provide infrastructure that made it easier to take read-only sources from outside the project and to echo them as read/write entities within the project. I told you how to do that but it appears you either did not read what I suggested or that it was too onerous to accomplish. I fully agree that if something is too challenging people will often blow it off. But the solution to that is not to pile on with more elaborate error messages, it is to make the task easier.
So, for now, if you want to assign styling you do have choices:
1. Use a read/write data source that allows storage of styling within the format. If you look at the new GPKG screenshot in the Radian Gallery page, that shows an example of styling that is applied to and stored within the very same .gpkg file downloaded from the New Zealand government. It is convenient to be able to give someone a .gpkg file and when they open it in Manifold they see the styling you assigned.
2. If you want tricky (ahem, "sophisticated") controls over who gets to specify styling with other data guaranteed kept untouched, use a sophisticated data source like a DBMS (PostgreSQL comes to mind) where you can, as administrator, have fine control over who gets to change what tables and even fields. You can then do very intricate administrative things like have standardized styling that cannot be changed by users even if they are allowed to add, edit and delete objects.
3. Leave the data in the read-only file but then arrange to have styling kept in the project, like in the links I recommended. The easiest way to do this is to on a one-time basis make the gpx read/write so you can create a geom in there, so it is possible to link a drawing to it in a very simple way, and then make it read-onlyso nobody can mess with the data after that.
I've offered to show you how to do this if you post the GPX. I'm mildly surprised that if this is a big deal you haven't done that.
By the way, on a philosophical note, to add value despite the limitations of GPX you surely can use Manifold. But when you store all that extra value stuff in a .map project you are undertaking the classic addition of "hair" that people do when, say, they want to get around the limitations of shapefiles by adding all sorts of accessory files, such as .prj or .lyr files. All those then must continue onward as an ensemble or you lose the value-added they provide. If, really, GPX has limits you don't like it probably is time to consider a more sophisticated format, such as GPKG, that does not have such limits.