I don't think adding this to AccessRestrictionType is the right thing to do. Currently all the bits defined for this type are very static in nature. Introducing a very dynamic 'locked' status seems wrong.
Can you propose another option?

EVERY OPC UA Service call (Browse, Read, Write, Call...) must check

• RolePermissions
• AccessRestrictions
• AccessLevel (Variables)
• Executable (Method)

Therefore I do not understand the comment about 'static'. The values of these attributes may change infrequently but they can all change. But the check with these attributes must be done for most OPC UA Services for every single Service call.

RolePermissions is related to Roles and does not fit with the locking.
AccessLevel is only available for Variables
Executable is a boolean that can not be extended with another flag.

If we do not want to introduce another attribute, AccessRestrictions is the only option.
Even the name fits perfectly. A locked node has access restrictions. The name is not 'PermanentAccessRestrictions'

A Server needs to check before an operation is performed - that should be considered "normal" because the responsibility for access checks lies with the server, and the check must be made at the instant the client request is received.

For a client to do the checking before it attempts an operation is sub-optimal because
1) creates a race condition where the client checks the access, gets the OK, and before it can perform the operation the lock status changed.
2) it does not scale to thousands/millions of nodes
3) imposes significant performance costs and complexity to otherwise simple and fast operations.
4) Reading the attribute prior to requesting the operation will be wasted if the value has not changed.

I'd prefer a solution where the client subscribes for notifications that are reported when changes in locking occurred. This mechanism can be extended to include other changes in otherwise static attributes, such as a change in engineering units. There may still be a race but at least it eliminates an unnecessary attribute read

From the description it is not obvious why the 'locked' state has to be in a standard attribute. Do we expect that Clients read this and then do not execute certain calls? See also David's "sub-optimal" note.
Servers can have an internal attribute with this locked state.

Is it expected that the LockingService defined in Part 100 also adds the "HasLockOwner" references? has to be optional only to avoid a breaking change.

This needs to be designed in conjuction with an entire feature.