I completely agree that each car could do it.
Teslas operate on "Feature Flags" from software development for the hardware installed. These values are stored in the Gateway config file of the Gateway LIN/CANBUS controller within the MCU. You must have a certain level of access to the Tesla Toolbox 2/3 diagnostic tool to make changes to that file or be really good at decoding, accessing, and modifying Linux systems to change the values directly.
As with any vehicle, it's all parts, wiring, and code these days. The problem is Tesla wants to be the only one to access the code on vehicles we own. This is very similar to how Apple operates their ecosystem. Controlling the software, firmware, and features in each product.
Tesla vehicles though, aren't architected like other auto manufacturers cars. It's all code written by Tesla, MCU designed by Tesla, Body Controllers designed by Tesla. The feature flag values set in the MCU on the Gateway are then programmed into the Body Controllers (VCFront, VCLeft, VCRight, Charging Controller, HVBattery Controller) during a software deployment (it deploys software and firmware to all the subcomponents in the car too like the Matrix Headlights, iBooster, USS, Cameras, iTuner, Seats, etc...). That's why often times when an "upgrade" is available for a vehicle, or they change an electronic component. They need to reinstall the current software version. Like the recent Round Steering wheel vs the Yoke for the latest Palladium/SOP14-16 Model S cars.
MCU2 vehicles with Matrix lights have been limited to Model 3 (maybe Y?) cars. "If" the MCU2 Model 3s and the MCU2 Model Ss share the same build branch, then the "Feature Flag" for Matrix lights may be present and configurable. Since MCU2 Model S vehicles never came with Matrix lights that subcomponent of code may not be present. It really comes down to how Tesla manages their software branches for the code deployment across different vehicles.
Not trying to be argumentative, just sharing what I know on why I'm saying, "It depends."