This seems to be the expected behavior considering you are updating the same field from a workflow update too. If you see the Triggers and Order of Execution documentation, and refer to the below excerpt from the documentation, this seems to be coming into picture here.
Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger doesn’t contain the version of the object immediately before the workflow update, but the object before the initial update was made. For example, suppose that an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, rather than 10, as would typically be the case.
Taking a stab here as what I think is the flow in your case:
Create a number field say - TestNumber
Wrote a trigger. In before context, updated it +1. (Value here is 2)
Have a workflow which will in turn update same field by +1.
(The workflow actually worked again on Value 1 here because of the
reference above, so the Value here now is still 2 after
incrementing by 1 on the Old value 1. Now because of the field
update triggered from a workflow, the before and after triggers are
executed again (refer the order of execution). So the final value
out of this process would have been set again in the trigger which
will be 2+1 = 3)
Have a process builder which is running one no criteria. It has 2 actions:
- i. Update same field +1 (Value here is now 3+1 = 4)
- ii. called an invocableMethod and print value of testNumber__c