If a Server does not want to support this, it can return an error if a client attempts to use an index range on a Variable. A capability flag can be added which indicates if it is supported or not.

Just my two cents:

• If the integer represents a collection of bits instead of a number, it could be better to model this as an OptionSet (see Part 5, chapter 12.2.12.8) which allows setting only a subset of the bits.
• The problem with OptionSet and also your suggestion is, that data consistency is difficult to achieve on devices whose operation must be fast and deterministic (real time). A transaction service (an atomic read-modify-write) to data belonging to the real time process would lead to inacceptable delays. Of course such devices may return an appropriate return code, but what is the worth for a client, if it can't find out in advance whether a variable supports this and always has to try out and always has to implement a fall-back?
  (Yes, this argument is also valid for the existing subrange access on array variables ...)

An OptionSet is a good solution, but is not always possible. The problem with modeling this as an OptionSet is that it requires the Server to have advance knowledge that it should be exposed this way, and this is not always known when the Server creates the address space. If it is not part of the address space, it becomes impossible for a client to access it this way without modifying/rebuilding the model.

There are use cases where only the client knows which Nodes should be handled this way. In a distributed system with many clients, perhaps only some clients need this functionality, and others do not.

When a Client writes any value to a Server there is no expectation of realtime behavior, but the concern is data consistency - the corruption window is the time between when the Server read the value from its source and when the client writes the modified value back to the Server and it is forwarded to the data source.

If it is implemented in the UA Server, the window is between the time the Server reads the value from the data source and writes it back again - a big chunk of the latency is gone. If RMW is implemented in PLC or device firmware then both data consistency can be guaranteed along with deterministic behavior.

The feature is optional, so the Server and/or data source does not need to implement it.
The fallback (and currently the only way to do this) is for client-implemented RMW, which is the least preferred mechanism due to the potential for data corruption.

Discussed in meeting. Reading may be overkill since it is easy for a Client to mask off the undesired bits, but writing a subset of bits should be supported. May be particularly useful when using the new "bitfield" type (see related mantis issue).