The described sequence also leaves the data type from the prior User Field.  In summary the User Field name gets updated, the value does not get updated, the red x delete icon does get updated, the field data type does not get updated.

Failure to update displayed value in Fields dialog causes changes to user field values on insertion:

In addition, the behavior described in the original post creates a risk of the user inadvertently changing the value and format of User fields, when inserting them in the document.

Replication steps:
The steps below describe how to observe the problem changing field values. The same steps, but varying field formats as well, will show the formats also changing.

Set up User Fields:
1. Open a new document
2. In the menu bar, select View: Field Names. This allows the user to see the inserted field names as well as the values.
3. To open the Fields dialog: 
    a. In the menu bar, select Insert: Fields: Other... 
    -or- 
    b. Hit <Ctrl><F2>
4. In the Variables tab:
    a. In the Type box select User Field.
    b. In the Format box select Text (this will give good recognizable flexibility on field contents)
    c. In the Name box type a unique name.
    d. In the Value box type a unique value.
    e. Click the green check-mark to apply the field to the document (this does not insert it in the document text.)
    f. Repeat for another field name and value, so that there are two defined fields for the document.
        Observe that for both fields the green Apply check-mark and the red Delete X are both enabled.
    g. In the Selection box, click one field then the other.
        Observe that the name and value displayed in the text boxes below update to the selected field values.

Testing:
1. In the selection box, select the first field.
2. Click the green Insert check-mark.
    a. Observe that the field value has been inserted in the document
    b. Observe that the red Delete X has become disabled. A User Field cannot be deleted from the list of fields while it is in use in the document.
3. With the cursor in the document, Hit <Enter> after the inserted field, to give some visible separation.
4. Return to the Fields dialog.
5. Click the first value in the Selection box
    a. Observe that the Name and Value have updated.
    b. Observe that the check-mark is enabled but the X is disabled.
6. Select and delete the name in the Name box.
7. Type the name of the second field in the Name box
    a. Observe that, as the name is completed, the X becomes enabled. This is evidence that the second value is now selected.
    b. Observe that the Value field still contains the value of the first field. 

The field value not being updated in the UI is the core of the problem. The next few steps show how this can cause unintended changes to user field values.

8. Click the Insert button.
    Observe that the second field has been inserted into the document at the cursor, but the inserted value is that of the first field.
9. In the Selection box, select the first field. 
    Note that its value is intact.
10. Select the second field. 
    Note that its value has changed to that of the first field.

(In reply to joezbugz from comment #2)

My replication was done on version 4.1.1 on Windows7 running on an HP EliteBook 840.

There is a mistake in step 2 in the testing section. It should read:
    2. Click the Insert button.

To clarify step 6 in the testing section:
    6. Place the curser in the Name textbox and clear/delete the name text.

> 
> Testing:
...
> 2. Click the green Insert check-mark.
>     a. Observe that the field value has been inserted in the document
>     b. Observe that the red Delete X has become disabled. A User Field
> cannot be deleted from the list of fields while it is in use in the document.
...
> 6. Select and delete the name in the Name box.

I was able to successfully replicate the bug with the steps outlined by joezbugz while on OpenOffice version 4.2 (Build:9800) with Windows 10.

To further exemplify on the issue it seems that the entries in the Name field are not case sensitive either, even though they will be written as such. 
For example if you: 
1) write Test into the name field with a value of 123
2) write TEST into the name field with a value of 456
Instead of creating a new Selection for the user field it will update the previous 
Value.

It seems that whenever you update the Name field to a new entry and click "Insert" it will create a brand new field entry under the selection box. This is also true if you were to click the green apply check-mark; however, it will no insert the User Field into the text document. I believe the issue lies in the fact that a new entry is created whenever there is a new name in the Name Field and that it will always treat is as a new and Unique Name even if that current name is found in the Selection field.

Written and Tested by: Tyler Martinez on 02-25-2017

I was able to reproduce the behavior (the Name and Value inputs are not in sync when the name for a field is updated to a name of another existing field) performing the steps and suggestions provided by joezbugz@outlook.com and Tyler Martinez on Windows 10 on
- AOO420m1(Build:9800) - Rev. 1785175 Rev.1785175 on
- A00 4.1.3

The behavior seams to be related to how Apply and Insert buttons work for newly or already existing fields.

1. Navigate to Insert > Fields > Other.. > Variables > User Field.
2. In the Name input, set an user field UF1 having value 12.
3. Click on Insert button.
Actual results:
- a new item UF1 is added in the Selection list
- the UF1 value, 12, is added into the working document.

4. Press Enter into the document (in order to better distinguish between the fields that will be added in the next steps). This step should be performed after each field insertion into the document.
5. In the Fields screen, select UF1 item and update its value to 122.
6. Click on Apply button.
Actual results:
- into the working document, the user field's value is 122.

7. In the Fields screen, create a new user field, UF2, with value 34. Click on Insert button and notice the field is added to the working document.
8. In the Fields screen, having focus on UF2 user field (its value is 34), update the Name input to UF1.
9. Click on Insert button.
Actual result:
- a new value, 34, is added into the working document - if hover over the field, its label is UF1.
- the previously inserted values for UF1 field are the old ones, 122.

10. In the Fields screen, move into the Selection list in order o notice the couple Name-Value for existing fields.
Actual: UF1 value is 34.

11. Having UF1 selected from the Selection list, click on Apply button.
Actual:
- UF1 field's values from the working document are updated to the last set value (122 becomes 34).


At first impression, it looks like the functionalities of adding and inserting user fields ALWAYS have the same behavior. 
Yet, their behavior is different depending if they are applied on a newly created field or onto an existing one:
1. For newly created fields:
- Apply saves the field into the Selection list
- Insert saves into the Selection list and inserts the field into the working document
2. For existing fields
- Apply updates all already inserted usages of the given field with the last set value
- Insert saves a new value for the field and adds it to the working document

I think that the underlying problem might be that by setting a value from the Selection list into the Name input would, the value and Format properties of the field aren't automatically displayed - in other words, setting a valid user field name in the Name input could behave as a filter.
This might be the wanted behavior or not - in either way, it is quite confusing for the user.

There is a similar issue 
https://bz.apache.org/ooo/show_bug.cgi?id=3070
This could be a duplicate of this issue may be? Paul roubekas could help describe if the issues are similar?

From retesting this issue 
1. I was able to replicate the issue just as the well defined steps in the attachment, thank you.
2. I believe this is a design flaw but working as expected since I could not find any requirement other than the below that says 
"Inserts a custom global variable. You can use the User Field to define a variable for a condition statement. When you change a User Field, all instances of the variable in the document are updated."

So as per the requirement the design works however it gets really difficult to manage these user variable when the table gets really big.

It would be nice to have the enhancement to handle user fields by tightly coupling them to each other. User Selection to Value to the value inserted in the document. 

(In reply to Jessa from comment #6)
> There is a similar issue 
> https://bz.apache.org/ooo/show_bug.cgi?id=3070
> This could be a duplicate of this issue may be? Paul roubekas could help
> describe if the issues are similar?

Created attachment 86102 [details]
Userfield Help Text from Open office writer

Attaching the open office writer user field specification from the help.

I wanted to make my description a little more clear. 
1. Looks like there is a similar bug to this
     https://bz.apache.org/ooo/show_bug.cgi?id=3070
2. I was able to replicate the issue just as the well defined steps in the attachment, thank you.

3. I believe this is a design flaw but working as expected since I could not find any requirement other than the below that says 

"Inserts a custom global variable. You can use the User Field to define a variable for a condition statement. When you change a User Field, all instances of the variable in the document are updated."
note: I have got the description from open office write help on user variables. <see the attachment>

4. I tested similar functionality in Microsoft word 2016
  you can either use     
    Docvariable or Docproperty under Quick part (fields or docProperty) to add user variables.

  The advantage of this is the user error can be reduced when the user variable list gets rather large in the Variables -> Selection. 

Lets say you have 1000s of user variables and if the document is being shared by more than one person its difficult to keep track of all the user variables already entered. 
Having similar function as DocVariable where you enter lets say "Open W" the system will complete the word for you or have similar function like docProperty where you can enter values to fixed user variables would be good.

(In reply to Jessa from comment #9)
> I wanted to make my description a little more clear. 
> 1. Looks like there is a similar bug to this
>      https://bz.apache.org/ooo/show_bug.cgi?id=3070


No! Issue 3070 talks about Custom Properties (File → Properties: Custom Properties) and is not valid anymore.

That the value and format not change if you create a new User Field can be considered as bug but also as feature if you create a template with many User fields that have the same predefined value. It is the intention for an User field that its value will be defined when working with the document, not at creation time.

But YES: In my opinion if one type the name of an existing User field and the cursor leaves the name field the value field should show the actual value of the User field.

But what is with the format of the User field? This is not so easy because there can be more than only one format.
Example:
1. Insert an User field “MyVar1” with value “3”, format “-1234.12”.
2. Insert an User field “MyVar2” with value “MyVar1+1.23”, format “Formula”.
3. Insert again an User field “MyVar2” with value “MyVar1+1.23”, but with format “-1234.12”.

(If you swap 2. and 3. it may be that you must open the numeric User field and approve the value again.)

There are filed other issues that shows that the UI for variables needs a redesign. Especially if one works with a lot of variables and/or the variables have long names.