anchor.diff:          .build();
        bucket.replaceConfiguration(newConfiguration, TokensInheritanceStrategy.PROPORTIONALLY);
   ----
  -.There are following rules for bandwidth identifiers:
  +.There are the following rules for bandwidth identifiers:
   * By default bandwidth has <b>null</b> identifier.
  -* null value of identifier equals to another null value if and only if there is only one bandwidth with null identifier.
  -* If an identifier for bandwidth is specified then it must be unique in the bucket. Bucket does not allow to create several bandwidths with the same ID.
  +* null value of identifier equals to another null value if and only if there is only one bandwidth with a null identifier.
  +* If an identifier for bandwidth is specified then it must be unique in the bucket. Bucket does not allow to create of several bandwidths with the same ID.
   
   ==== TokensInheritanceStrategy explanation
   *TokensInheritanceStrategy* specifies the rules for inheritance of available tokens during configuration replacement process.
  
positive.code: .AS_IS strategy examples:
  ** *Example 1:* imagine bandwidth that was created by `Bandwidth.classic(100, Refill.gready(10, Duration.ofMinutes(1)))`. +
  +
  At the moment of config replacement it was 40 available tokens. +
  +
  After replacing this bandwidth by following `Bandwidth.classic(200, Refill.gready(10, Duration.ofMinutes(1)))}` 40 available tokens will be just copied, and after replacement we will have 40 available tokens.
  
  ** *Example 2:* imagine bandwidth that was created by `Bandwidth.classic(100, Refill.gready(10, Duration.ofMinutes(1)))`. +
  +
  At the moment of config replacement it was 40 available tokens. +
  +
  After replacing this bandwidth by following `Bandwidth.classic(20, Refill.gready(10, Duration.ofMinutes(1)))` 40 available tokens can not be copied as is, because it is greater than new capacity, so available tokens will be reduced to 20.
  
  RESET::
  Use this mode when you want just to forget about the previous bucket state. RESET just instructs to erase all previous states. Using this strategy equals removing a bucket and creating again with a new configuration.
  
negative.code:     .build();
  bucket.replaceConfiguration(newConfiguration, TokensInheritanceStrategy.AS_IS);
  ----
  It is obvious that a simple strategy - copying tokens by bandwidth index will not work well in this case, because it highly depends on the order in which bandwidths were mentioned in the new and previous configuration.
  
  ==== Taking control over replacement process via bandwidth identifiers
  Instead of inventing the backward magic Bucket4j provides you the ability to keep control this process by specifying identifiers for bandwidth,
  so in case of multiple bandwidth configuration replacement codes can copy available tokens by bandwidth ID. So it is better to rewrite the code above as follows:
  [source, java]
  ----
  Bucket bucket = Bucket.builder()
  