Michael,
I don’t think scenario #1 is a good reason for NULL instance of SmmAccessLib. The root cause is BoardInitLib lib class supports pre-mem and post-mem board init.
Below solution can avoid NULL SmmAccessLib:
Create two instances of BoardInitLib for pre-mem and post-mem. Pre-mem one doesn’t link to SmmAccessLib.

For scenario #2, if a particular platform doesn’t support S3, why does this platform include the PEIM?

Please understand that I want to avoid introducing more abstraction layers.

Thanks,
Ray

From: Michael Kubacki <mikuback@linux.microsoft.com>
Sent: Friday, August 13, 2021 10:16 AM
To: Ni; Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-platforms][PATCH v1 1/1] IntelSiliconPkg: Add BaseSmmAccessLibNull

Sure.

Scenario #1:

MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.inf and MinPlatormPkg/PlatformInit/PlatformInitPei/PlatformInitPostMem.inf both link against an instance of BoardInitLib.

Many boards link against a single BoardInitLib instance. See example - https://github.com/tianocore/edk2-platforms/blob/cd4e6b716c7d1bcde94035e7dce14b53a553e103/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc#L203

That BoardInitLib instance may link against SmmAccessLib. PlatformInitPreMem may wish to library class override the SmmAccessLib to the NULL instance while keeping it to non-NULL instance in PlatformInitPostMem.

Scenario #2:

A PEIM is built that checks whether the boot mode is S3. If so, it calls PeiInstallSmmAccessPpi(). A particular platform does not support S3, therefore, it links BaseSmmAccessLibNull as its library instance for SmmAccessLib.