Explanation:

🌍 Why Custom Objects Work Best for Multi-Country Selector Data
When building a country selector that needs to store multiple data points per country — such as a pricebook reference, flag image URL, or other configuration values — the most flexible and scalable solution is using Custom Objects.

✅ Option B: Replicable, Site-Specific Custom Object
Custom Object Type: Create a type like CountryConfig
Each object instance holds:
Country code (e.g., US, FR)
Pricebook ID
Flag image URL
Any other relevant metadata
Replicable: Ensures the data is pushed from staging to production
Site-specific: Keeps data confined to one site (important in multi-site realms)
📘 You can access these easily via script or controller logic using:
CustomObjectMgr.getCustomObject('CountryConfig', countryCode);

❌ Why A & C Are Not Suitable

A. Extend the Locale System Object
System Objects like Locale are not customizable, and their scope is global — they can’t store arbitrary key-value data

C. Content Assets
Best for static or visual content, not structured config logic like pricebook mapping — hard to query and maintain programmatically

🔗 Reference:
“Custom Object Types allow developers to create structured, extensible models to store and retrieve configuration data. Replicable and site-specific types ensure deployment flexibility and multi-site isolation.” — Salesforce B2C Commerce Developer Guide
📖 Custom Object Type Documentation