A quick recap of the meeting, for those interested, starting with the conclusion first:
Conclusion
While it was decided that OEP-45 is not the right place to refer to a reference deployment implementation directly, edX agreed to add some wording to it addressing the community’s most pressing concern: that the possible future deprecation of edx-configuration could lead to the loss of visibility into how edX does deployments.
In other words, while not everyone actually uses edx-configuration for deployment, a lot of community members do use it as a reference; if it goes away (at once or incrementally), prior to the meeting there was no guarantee, written or otherwise, that information coded exclusively in edx-configuration would continue to be provided. The primary example given was the LMS nginx configuration: it is currently an important bit of deployment lore that would be deprecated by OEP-45, but for which OEP-45 offers no provisions.
With that in mind, @billatedx was already kind enough to add some wording to alleviate this concern. In short, if something is taken out of edx-configuration and it’s important for deployment, it will be replaced by an equivalent source, and made publically available. Thanks, Bill! 
But will there be a reference deployment implentation, after all?
The short answer, for now, is: possibly. And one of the main options is to make it the devstack.
We arrived at this possibility by recognizing that even if edX doesn’t publish the full solution that it actually uses for production deployment after OEP-45, or if it does publish it but doesn’t make it a one-stop-shop like edx-configuration, then if:
- a simplified but feature-complete deployment implementation is made available, and
- it uses the same Docker files (though not necessary the same images) that are to be produced as part of OEP-45, and
- it is subjected to CI/CD so that everybody’s alerted to deployment problems ASAP,
such an implementation would probably be a good-enough, stable, and guaranteed-to-work-with-master reference deployment for the community to use as a basis for their own projects.
If the devstack were to conform to the above, then it would be a prime candidate. Particularly given that edX does actually use the devstack to develop edX. (I wasn’t sure, but Bill confirmed it. ;)) Plus, such an outcome would mean that the devstack would move closer in step with the master branches it uses, resulting in a likely more stable development experience.
To reiterate, though, this is for now only a possibility. edX has agreed to continue discussion on the topic once OEP-45 is approved and progress starts on an actual implementation plan.
Thanks to all that participated! If I missed something, or got anything wrong, please feel free to correct me.