So, the first quote describes what the author means by "Abstract Core". When modeling the Core Domain, you are going to have "surface level" elements that are visible to clients (the application logic, use cases), and act as an API to the "inside" of the core, so that you can manipulate the implementation details when developing/refactoring. These "surface level" classes / functions / data types represent the fundamental capabilities of the core model, and are, ideally, designed to be expressive enough so that the logic of the clients can be expressed in terms of those elements; this is the Abstract Core.
In the book, when a concept is rendered in ALL CAPS, it generally means that it's a reference to a concept defined elsewhere in the text.
Now, having an abstraction (such as an Abstract Core) does not automatically mean that it's extensible, or that the behind-the-scenes implementation is partially or fully swappable from the perspective of clients, or via a composition root (if the application is using DI). In case of "fully swappable", the Abstract Core presumably performs some useful higher-level function. To support this kind of extensibility, the Abstract Core needs to be specifically designed for it (and this is not necessarily an easy thing to do well, and not without costs, so this shouldn't be taken as a rule, but as one of the options to consider). You need to plan for & define extension points where external code can be plugged in (e.g., by implementing an interface or a base class, and registering itself via some API). So in the second quote, the emphasis is really on the "and create a framework that allows diverse implementations of those interfaces to be freely substituted."
For the last bit, "allow any application to use those components", imagine a library of reusable components (not generic ones, but for a specific aspect of a domain) that clients (or application compositors) can freely pick and plug in into this framework to configure for the functionality they need, or a scenario where each application team can make use of the services provided by the Abstract Core, but develops their own components for details. The client logic itself would go through the framework / abstract core; this requires some programming discipline, team maturity, and it puts a bit of a burden on clients in the sense that they need to be aware of (some of) these components in order to pick the ones that are suitable for their needs; this can be mitigated if you can provide sensible defaults.
Note that this chapter starts with:
Opportunities arise in a very mature model that is deep and distilled.
A PLUGGABLE COMPONENT FRAMEWORK usually only comes into play after a
few applications have already been implemented in the same domain.
So, the idea is that this is something that may be produced as a result of refined understanding of domain concepts over several applications, each of which likely has its own model (representation) of the same domain, with significant conceptual overlap. The Abstract Core in this scenario captures that overlap (i.e., it does something of central value to all those applications), and is also designed to support application-specific needs by allowing for pluggable behavior. The book also notes that efforts in this direction have had mixed success, with those doing this later rather then earlier (so, after several applications have already been developed) being more successful.