I was unable to find any issue or discussion related to what I described below and so decided to create a ticket.

After change 73e382fa877f80994817a136b0adcc4365ccd904 `LocalCache` implements its own versions of methods like `computeIfAbsent` and `computeIfPresent`. These replace previous implementations inherited from `ConcurrentMap` with ones that delegate to unconditional call to `compute` with customised lambda e.g. `computeIfAbsent`:

```java
 return ((v = get(key)) == null &&
                (newValue = mappingFunction.apply(key)) != null &&
                (v = putIfAbsent(key, newValue)) == null) ? newValue : v;
```
becomes:

```java
compute(key, (k, oldValue) -> (oldValue == null) ? function.apply(key) : oldValue);
```

This has side effect that even if value is already present it is replaced by itself which confuses removal listener that will report value being removed with `RemovalCause.REPLACED`. Stats are possibly also incorrect (not used them to date so I am not sure).

Below test case reproduces this behaviour.

```java
List<RemovalNotification> notifications = new ArrayList<>();

Cache<Integer, Integer> cache = CacheBuilder.<Integer, Integer>newBuilder()
        .removalListener((RemovalListener<Integer, Integer>) notifications::add)
        .recordStats()
        .build();

cache.asMap().computeIfAbsent(1, integer -> integer + 1);
cache.asMap().computeIfAbsent(1, integer -> integer + 1);

assert notifications.size() == 1;
assert notifications.get(0).getCause() == RemovalCause.REPLACED;
assert cache.stats().evictionCount() == 0;
assert cache.stats().loadCount() == 2;
```
* changing any bin. The operations must not take any action that could even momentarily cause a
     * concurrent read operation to see inconsistent data. This is made easier by the nature of the
     * read operations in Map. For example, no operation can reveal that the table has grown but the
     * threshold has not yet been updated, so there are no atomicity requirements for this with
     * respect to reads.
     *
     * As a guide, all critical volatile reads and writes to the count field are marked in code
     * comments.
     */
    @Weak final LocalCache<K, V> map;
    
    volatile int count;
    
    @GuardedBy("this")
    long totalWeight;
    /**
     * Number of updates that alter the size of the table. This is used during bulk-read methods to
     * make sure they see a consistent snapshot: If modCounts change during a traversal of segments
     * loading size or checking containsValue, then we might have an inconsistent view of state so
     * (usually) must retry.
     */
    int modCount;
    /**
     * The table is expanded when its size exceeds this threshold. (The value of this field is
     * always {@code (int) (capacity * 0.75)}.)
     */
    int threshold;
    
    @MonotonicNonNullDecl volatile AtomicReferenceArray<ReferenceEntry<K, V>> table;