What is the difference between a conventional and an RNAV holding?

Question

While reading in the PANS-OPS (Doc 8168-OPS/611 Volume II) about holding procedures, I came across Chapter 7 of Part III section 3 defining RNAV holding procedures and differentiates them from conventional ones described at an earlier section. Under 7.1.3 is mentioned that

Location and number of holding patterns [...] The normal location would be at one of the IAFs. RNAV holding waypoints shall be located so that they are referenced to and verifiable from specified radio navigation facilities. The holding waypoint (MAHF) is a fly-over waypoint.

At that point I recalled the GNSS RNAV procedure from BEDEX for LGKR airport. There we can see that note #2 warns us that the holding is a conventional one. But why can't it be treated as an RNAV? It's on the IAF, it's defined by KRK VOR/DME (thus verifiable and from specified radio navigation facilities), even the path to MAHF (Missed approach holding fix) seems to be a fly over.

The rest of the chapter is defining the geometry protected areas etc that from the description I would expect them to be smaller than that of the conventional holding pattern:

Aircraft equipped with RNAV systems have the flexibility to hold on tracks which are defined by the RNAV equipment and to use procedures which are less rigid than those used in conventional holdings. The benefits of using this technique include the optimum utilization of airspace with regard to the siting and alignment of holding areas as well as, under certain circumstances, a reduction of holding area airspace.

So what makes conventional holdings "incompatible" to RNAV?

Answer 1

A conventional hold based on legacy radio-navigation required overflying the hold fix on entry as guidance is only available inbound to the fix and your exact position is known at the fix (with some allowance when inbound if there's a DME at the holding fix.) Hold entries from the holding side of the inbound leg will result in crossing to the non-holding side of the inbound course and thus require protected airspace on the non-holding side. The outbound leg of the hold is normally defined by time based on published holding airspeed. Protected airspace has to allow for wind factors and the limited navigation accuracy when flying the hold.

With an RNP capable FMS or GNSS-based navigator, the path of the racetrack can be defined and flown with guidance throughout the hold (including entry and exit.) As a result the Minimum Aviation System Performance Standards: Required Navigation Performance for Area Navigation (RNP MASPS, RTCA DO-236) require containment within the maximum size holding pattern defined in the MASPS. The key differences are entries are not required to overfly the fix (fly-by is allowed) when entering from the hold side to avoid crossing to the non-hold side. Entries from the non-hold side (teardrop and some direct entries) typically will overfly the fix. Once the aircraft has entered the hold it is expected to fly the hold as specified until it exits. Exits can be either fly-over or fly-by the holding fix as published.

The biggest change is in a parallel entry. Entry is a fly-by the hold fix to fly outbound on the inbound course, followed by a 225 deg/45 deg reversal on the holding side to join the inbound course and cross the fix to be established in the hold.

Direct entry from the hold side results in the initial outbound turn extending further past the hold fix as a result of the initial fly-by at the hold fix. The aircraft is then established in the hold when it joins the outbound leg.

Since the RNP nav system can provide path definition of the hold and guidance the total protected airspace can be reduced when compared to the conventional hold.

Conventional holds are not in general incompatible with RNP holds. An RNP capable FMS will treat all holds as RNP holds. The only issue I see here is the comment: DEFINED BY USE OF KRK VOR/DME. That would indicate to me there is an inconsistency between the VOR/DME computed positions and the fix positions contained in the database.