Exercise 3: "Compatible Today" vs. "Interchangeable Forever" — Possible Solution
====================================================================

WHY "COMPATIBLE TODAY" ISN'T THE SAME AS "INTERCHANGEABLE FOREVER"
------------------------------
Per this chapter's own warn-box, "because of the ongoing, independent
divergence this chapter covers, a client library, plugin, or piece of
tooling written or tested against one of the two engines is not
guaranteed to keep working correctly against the other, even if it
happens to work today." Per this chapter's own earlier material, the
two engines share a real, common ancestor (the 2021 fork point per
search1-2), which is exactly why so much basic functionality still
overlaps today. But per this chapter, "each project has developed its
own features independently, on separate release cycles, without the
other" ever since — meaning the two codebases are continuously
drifting further apart with every new release each project makes on
its own. A piece of software that happens to work correctly against
BOTH engines today is really only confirming that, as of THIS specific
moment and THESE specific versions, the particular features it relies
on haven't yet diverged. That's a snapshot of the current state, not a
structural guarantee about the future — nothing prevents either
project's own next release from changing exactly the behavior that
piece of software happened to depend on.

WHY THIS IS A REAL, PRACTICAL RISK, NOT JUST A THEORETICAL CAVEAT
------------------------------
Because the two projects have no coordination mechanism keeping them
in sync (per this chapter's own "separate release cycles" point),
divergence isn't a hypothetical possibility — it's the expected,
ongoing, ordinary consequence of two independently-developed projects
continuing to evolve. Relying on the ASSUMPTION that "it worked with
Elasticsearch, so it'll work with OpenSearch too" (or vice versa) is
relying on shared ancestry to substitute for an actual, current check
against the specific software actually being used.

THE RESPONSIBLE PRACTICE THIS CHAPTER RECOMMENDS
------------------------------
Per this chapter's own warn-box, "genuinely testing against the
specific engine and version actually being deployed — rather than
assuming interchangeability based on shared ancestry — is the
responsible practice." Rather than assuming compatibility based on
the two projects' shared history, the recommended practice is to
actually test any client library, plugin, or tool directly against the
EXACT engine and EXACT version a real deployment is actually going to
use, treating each combination as something to verify concretely
rather than infer from the other engine's own known behavior. This
mirrors this chapter's own broader guidance (per its "Practical
Approach to Choosing" section) of checking CURRENT, up-to-date
information for the specific situation at hand, rather than relying on
older, potentially-stale assumptions about how similar the two engines
still are.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains precisely why shared ancestry produces present-day
compatibility without guaranteeing FUTURE compatibility, given the
ongoing, uncoordinated divergence the chapter describes, and states the
chapter's own specific recommended practice (test the actual engine/
version in use) rather than a vague "be careful" gesture.