I think I got my head around your request but unfortunately I cant imagine a scenario where it could be fixed. UNLESS it is possible to use some javascript to get the default value of the field and compare it to the saved value of the field and apply a css class if it matches

That's interesting since there must be code somewhere that checks whether there is an override value for the field (when the article is loaded into the editor?) and, if not, it uses the default. I'm certainly not familiar with that core code.

If there is no value saved for the field in the article then the default value is presented AND it is saved with the article

That could be problematic for my use case, which wants to use the custom field default value as the source for all instances of that field, always. If the article field value is saved and then the default value changes, that change won't propagate to those articles.

In fact, this is not the behavior I have witnessed. When I don't change the value at the article, the field default presides, even if the article is subsequently modified. I will confirm this later today, but this is why I have removed permission for field editing from all ACLs. I just can't do it for Super Users.

EDIT: Confirmed that editing the article does in fact apply the current default value as the article-specific value. So this is not the solution I need. I will have to write my own plugin, it would seem.

Dang it anyhow.

I just add, when you do not want default value then no need to use default value.
If you need to show "the value example" then you can use placeholder.

I have assumed that what Bruce wants is to set a default value of $10 today but in the future he wants to change the default value to $15 and he is expecting that this will make all future and existing articles with that field to be updated with the new value

@bascherz I just saw your edit. Can I assume then that this issue can be closed

Not necessarily. If it's doable, I'd still like to see this change.

Since I needed a solution ASAP, I did write a plugin that was cloned (more or less) from the core LoadModule plugin, specifically the {loadposition} variant, that simply plugs an alphanumeric value in for each tag you define. It supports any number of "pluggable" values. You define pairs of tokens and values with optional descriptions. The token is used like {plug my-token} in an article or custom HTML module. This allows the restaurant owner, in this case, to keep their menu the same, but vary the prices without editing any articles. The generic version of this plugin is called "Value Plugger", but the custom instance for this restaurant I named "Price List" and even created a Quick Icon to get to it quickly from the admin dashboard. So for her case, she puts in something like ${price 4-course-dinner} into her menu page.

I think changing how field default values work to lookup the default values of a field if there is no value set in the article's field instance would have made writing this custom (trivial) plugin unnecessary. And if that change is made, my original feature request to indicate when there is no local value and the default is being used is still valid. Alternatively, adding an option to make a field always use the default value would be good also. This supports using fields in a more globally-applicable way, as in my case.

if we were to change how the field works that would mean that we dont store the fields value with the article if it is the default. That would mean not saving the value of a field if it is using the default value but still render the default value if the field is empty. That would mean not having the ability to not set a value at all for the field. It would also mean that you could never search or filter by the value of the field as the field has no value in the article itself

Bruce what you actually asking is a default value for display.
The default value in the Joomla form is for storage, to be saved when User does not enter any value.
These is different things.

To do what you asking the value for storage should be empty. Then in layout you checking:

if value not empty:
  display value;

if value is empty:
 display default value;

These has own limitations, some of which Brian already wrote.

In theory it can be implemented in Custom field (because each of it has own layout), but I not sure we really need it. It can be even more confusing for Users to have 2 fields for default value.

I'm not asking to completely change how custom field default values work. Just asking if it's possible to add another option for cases such as mine. You both definitely have a grasp of the concept now.

I dont see how it can be achieved without considerable work and for the reasons I outlined I dont see it as beneficical - my 2c

Okay, it was just a request. If it's that big a deal, close it.

I could be wrong someone else might think it's easily resolved