In that case, consider a segmented product code, something like 101-001, where the first part is the base product type, and the second part represents the variation of that product. With three digits in each part, you could have a thousand products (or 900 if you don’t want leading zeroes in your product codes), each with a thousand variations. If that’s not enough options, add more digits to accommodate more products/variations. Obviously this would be cumbersome to track with each product in a new table, but with the help of Zapier or Integromat, the numbering scheme might still be something you could semi-automate. Here’s a quick mockup of what that might look like:
The Product Categories table is the master list of products by category, with an autonumber setup like I described above to give each category its own category code. The Products table is where all of the actual products live. When adding a record for a new product, you would choose its category in the Category field, which then auto-fills the Cat. Code field. Zapier/Integromat would then recognize the new record, count how many products currently exist in that category, and fill the Product Code field in that record with the next variation number in the sequence.
The building of the full code in the Product Code field may also be doable with formulas, though I can’t yet wrap my head around how that would work. Most likely it would require another table and some combination of lookups/rollups/etc. However, the issue I see there is that if you ever re-order your records in the Products table, the formula would likewise re-number the product codes with different variation numbers than they had before. By using an integration service, the Product Code field data is filled once by the service, and would stay unchanged if the record order ever shifts.