I live this scenario.
My employer's software has somewhere north of 1000 configuration flags, some with minor effects and others with the ability to dramatically change the system behavior. They support defining some 15 different kinds of item for sale, each with different rules of operation, 8 tax definitions (each of which can be defined in one of four configurations), and have multiple sale interfaces.
Since it's literally impossible to test all the possible combinations, we use a lot of automation and our coverage at the moment is approximately 20% of the system - but that 20% is specifically targeted to the configurations and interfaces that most of our customers use most often.
Because of this, we get very few bugs which can be added to our automation suites. The bugs that come in are typically things that can't be automated without a ridiculous amount of effort (a specific piece of hardware is not playing nicely with the software is a typical example) or that it's simply not worth automating (there's several hours of configuration to perform a 1 minute test that involves a configuration used by one customer who has no intention of upgrading, ever).
As far as exploratory testing goes, yes it is functional, but it's not worth getting hung up on terminology. In the example given, a smart tester will explore a semi-random selection of the potential combinations before targeting likely break points: can they configure the car to be a 2 seater with 4 doors? 6 cylinder electronic? And so forth. Often they'll document while testing and use their documentation to expand the functional documentation for the feature.
It's worth remembering that the label attached to any kind of testing is heavily contextual and one tester's functional testing is another's exploratory or risk-based testing. As long as you end up with a record of what was tested, why, and what the results were, I don't think it's all that important to fuss about whether it was functional, exploratory, risk-based, or some other kind of testing.