So, you could suggest it to the developers via uservoice.memento.com, if you'd like. Just search for it first, as it may already have been suggested. If you find it, you can add your vote for it there. If not, add/post your suggestion. You might consider saving the link to that suggestion and posting back here again; maybe we'll vote for it, too.
Of course, you could do it with a trigger, but it's more trouble to create a trigger, and having lots of them around just for this seems a little clunky.
Now that JavaScript in Memento is where it is, there are a few loose ends, right? The context for a JavaScript field is the Entry object you get in a trigger with entry(), but I haven't tested to see if all Entry methods are available. Global functions are not available, so you can't get access to other libraries, etc. I hope it is made so that a JavaScript field expression is just like a trigger, but Vasya may want to limit it to protect the casual expression writer from himself/herself by setting the context to the Entry object and thus disallowing wide-ranging scripts within a JavaScript field. I don't know. Things should be kept as simple as possible for the casual user, no?
Android imposes permissions so a user explicitly allows a program do read/write operations with memory, sms, etc., if he trusts the developer does not provide a malicious code and does not steal his personal data.
The Memento javascript environment, however, is solely controled by Vasya. It is up to him to decide on global "permissions" buttons. Which I kind of regard as "beautification" and redundancy. When I install Memento I already give read/write permissions. So why inventing more permission naggers? Sounds like "Are you sure you want to run your trigger?" at installation, and then asking again - "Are you sure that you are sure that you want to run your triggers?" after installation.
There is, however, another problem with JS field in this case. It is more about logic rather than implementability. Javascript is normally calculated - field by field. It means, that it is calculated once you edit an entry.
Now, suppose that the Library B's data has changed. So, does it mean that the user will have to do the recalculation of all Javascript fields for using the other library's updated data in the concerned entries?
Entry fields are established/recalculated after editing them rather than on opening the entry, as I see it. There is an option of recalculation of all fields - but that's slows down opening a library considerably, which is annouced. So, if you need to make a recalculation one global variable for all entries at once - one should use a trigger.
That's why the global functions should logically belong to library trigger which covers the whole library rather than individual entries.
It's fun seeing people that when they get something new - they would always want more. I don't see any obstacle on establishing a trigger and setting a value for fields in entries once they are opened. That wouldn't at all take more operations or code writing than JS field programming. Once again, it is not about implementability, simplicity or user-care, it is more about logic and sorting thing out to where they really belong, in my opinion.
The only exception, as I understand it, is that scripts and JavaScript field expressions are not scanned and changed, so it is up to users to do that manually. In my scripts, I try (:it's hard:) to set literals to variables at the top of the script, which makes this scanning minimal. Most of the literals are arguments to field() or set() functions. I recommend that you set your literals up front in your scripts. For example:
var fieldOrderNumber = "Order Number"; // At the top of the script or expression
...
var result = field(fieldOrderNumber); // JavaScript field
OR
ent.set(fieldOrderNumber, 0); // Trigger script
If you change the field name to OrderNo, you need to change only the line at the top, and it's sitting right there up front, eliminating a lot of scanning.
All name changes in the library structure need to be addressed -- not only field and library name changes, but also list item name changes and perhaps others. If you are saying that there are other changes to be made, I am unaware of them and would appreciate your educating me on this.
I do not understand what trigger is being requested, what it would do, or what kind of change made it necessary.