What do you mean by "Shared States"?
So far, each port (interface instance) state observed in a component had to be duplicated in the component and rigorously tracked to ensure that the observed state had exactly the same value in both the interface and the component. Dezyne 2.18 makes it possible to inspect the state of the ports. It can be used in guards and if statements. Most importantly, it can obliterate (together with implicit interface constraints) most state management in the component.What is the actual change between 2.17 and 2.18?
Below is an example implementation of timer interface. To track its status in Dezyne 2.17 it was mandatory to duplicate timer state in the component that implements it. Engineer must be sure to use same initial state and change the state according to interface behavior - every change in the interface behavior required similar, manual change in the component:
Dezyne 2.18 removes this obligation and provides free access to observe states of provided/required ports. This ensures that the component behavior contains only business logic and introduces full Component-Interface state awareness:
But what's the deal?
To emphasize the importance of this change being more than just a simple "code shortening", it is worth noting that the need to duplicate port state is the most common cause of "illegal" operations and added a lot of non-functional work and complexity. Below is an example error when you forgot to change the flag tracking the timer status at the time of its cancellation. The result is a very long and difficult to track error that can definitely spoil the mood and enthusiasm of implementing the new functionality.
An example application of automatic car high-beams implement using Dezyne 2.17 and 2.18.
Try commenting out some flag assignments and see what spectacular errors you can get 
AutomaticLights2_17.dzn (4.9 KB)
AutomaticLights2_18.dzn (3.6 KB)