Theoretically, there's no reason why that couldn't be possible. Conceptually, it would be wrong - "MOO" is data, and data belongs in a field.
If you like, you can define an unstored calculation field = "MOO" and use that as the matchfield in your relationship.
That is what we're doing right now, but that is precisely what we're trying to avoid, as having that extra field create much clutter in the table definition. Our system right now has close to 5100 tables, each with anywhere from 20 to 150 fields per table. Imagine trying to do that across a few hundred tables, and with multiple fields for multiple ER since many tables access like 20 other tables. We're litterally adding several such fields per table.
As far as the matching go, while 'MOO' would be data, the way the ER system work in filemaker basically make it the equivalent of a SELECT sql statement. There is no down side to specifying the static value in the ER definition, which would clean up the tables quite a bit and allow you to filter right then and there without having to go back to the table definition and create a new field.
To me, if something is in a database table, the cardinality should be more than 1, if it's you got like 1 thing in a table that has the same value for all records, that's kinda bad DB table designs.
"1 thing in a table that has the same value for all records" is practically Filemaker's definition of a global field. Filemaker has had global fields since the very beginning, I think (version 3 for sure), and I wouldn't expect them to change such a fundamental concept anytime soon.
The most one could hope for, IMHO, is being able to use a variable as the matchfield instead of a "real" field.
Our system right now has close to 5100 tables, each with anywhere from 20 to 150 fields per table. Imagine trying to do that across a few hundred tables, and with multiple fields for multiple ER since many tables access like 20 other tables.
I cannot imagine 5100 different tables. Each table should represent a GROUP, ie, Customers, Vendors, Invoices, LineItems and such. What could possibly make up 5100 different tables for a business? I suspect that you have many SAME tables which could be combined usiing one field called CATEGORY.
Are you sure you are relationally sound and properly normalized?
It's nearly 10 years of development for a financial services company with many many programs, all very complex.
A lot of it has to do with the lack of FM using variables, so some tables has like 150 fields in the table definition, but 50-60 are global variables being used as storage for things. While it all work, it create a massive cluttering with extra fields.