Might be better as g_TexturePriorityHigh/Low ?
Might also deserve a comment.

Why is it 0 and 1 here but u16 when passing it to the engine?
If cpp counterpart supports u16 priorities, why not support them here too and avoid the constants. (no questionmark)
Alternatively one could also introduce a Terrain prototype and add two Terrain.protype.FooPriority constants. That prototype could also be used to store the "Terrain entity" thing D1589. (But just ideas. In both cases it's affecting 70+ random maps)

But (same question)?

Well, I could just use the string "HIGH" and "LOW"

Why not simply no constants and having each texture define a number if it wants to use priorities (0 otherwise)?

If one wants to have a texture submissive around other tiles who also are submissive to some tiles, then the user would have to keep track of each of the tile's priorities and select a number which is less than the priority of those tiles. Which could quickly go out of hand when working with multiple tiles close by having different priorities.
Or maybe I am over estimating how much this would be used.

The only time I noticed this was in #4816. Maybe it could be used at the shoreline or when drawing paths to ensure that the intended border texture is visible.

If we want the priority system, it seems the easiest / most streamlined and most versatile way to mirror the engine as closely as possible.
Users can mess up the priorities sure, but they can do that with boolean priorities too.
Usually there is only one file (the mapscript) that defines the textures at the header, so it should not be terribly hard to keep track of the texture priorities.
A use case for 3 priorities = shoreline, path, ground texture all meeting in one place?

(I still didn't check what the C++ code actually does.)

What if you want the tile to the right to be rendered on top and the tile next to that and so on. It could go up pretty high technically speaking.

But logically speaking, it won't probably go higher than 3 as you mentioned.

I guess what @FeXoR suggested might work too. Calculating actual values when exporting.

It can also be 4+ by wanting to paint the path-texture always on top, the shore always on top of ground, the cliff texture always on top of the ground, the X always on top of the Z?

smiley said: "then the user would have to keep track of each of the tile's priorities"
That's why I proposed an array where texture priorities are given by the index in the array. The user then could search for the index of a given texture and insert another one before or after it. @elexis proposals like "cliff above other textures" could be realized by pushing them to the end of the list.
The texture IDs (less memory usage?) or the texture objects (less search for what texture relates to which ID so faster?) could go into that list.

(Is it really needed to give "terrains" (texture+entity/actor pairs) priorities? I really think that should be a property of the "terrain only" objects so the same "texture+priority" can be used in multiple "terrain"s.)

I am not sure how that would work. Each tile should have a priority. Not each texture. One could paint "red" in high position at one place and as low on another. I suppose this array should be storing tile coords or something. Which would be way less memory efficent and slower. Int16Array is faster than an Array of Uint16Arrays.
Unless of course, I misread what you said.

In a texturePriorityList IDs could be stored
In the IDToName array texture strings are stored by texture ID.
If we then use texture IDs before export to handle "textures" we can get the texture string for the texture map from IDToName and the priority for the priority map from texturePriorityList.indexOf(textureID). However, since texture strings won't be unique in the IDToName array any longer it couldn't be used to return an unambiguous ID. So IDToName and "if (texture in this.nameToID)" in getTextureID would have to be removed AFAICS (there are no other usages of that anyways).

I'm not in general opposed to a cell object but if we add it it should be extendable from within a map script (and I think that's not going to work without headaches?). Otherwise I'm for one map for each cell property (like it's now). But in case of texture priority we only need the property at map export so no need to add and update such a map during map generation.

Setting the priority as an argument of texture / Terrain creation sounds easy to handle for new maps and probably sufficient to gain the benefit at places where textures overlap?
The downside would be having to change all texture string definitions and library functions expecting strings to be Terrain instances?

The alternative would be to pass the priority to the TerrainPainter, but then it seems easy to run into the confusion troubles you mentioned earlier?

Currently:

const tDirt = "medit_dirt_b";
const tDirt2 = "medit_rocks_grass";
const tDirt3 = "medit_rocks_shrubs";

What I think FeXoR means:

const tDirt = "medit_dirt_b";
const tDirt2 = "medit_rocks_grass";
const tDirt3 = "medit_rocks_shrubs";

const tPriorities = [
 tDirt,
 tDirt2,
 tDirt3
];

But wouldn't this leave the header cleaner?

const tDirt = new Terrain("medit_dirt_b", 0);
const tDirt2 = new Terrain("medit_rocks_grass", 1);
const tDirt3 = new Terrain("medit_rocks_shrubs", 2);

(Just that it would come at the cost of possibly having to update all maps.)