Thanks, @joshrainwater.

I wrote up a big reply with my thinking on this behaviour and where would could and shouldn't change things...and in the process I think I convinced myself we may want ease restrictions across the board on Pennant ha!

Think I just need to sit on this one for a day or two to process my thoughts on the potential changes.

I think I've come around to the idea that we should not throw exceptions when you try to pass a scope value to a feature definition that does not support it. Instead, we should just return false and trigger an event.

Feature::defined('user-feature', fn (User $user) => true);

//

Feature::for(User::first()->active('user-feature'); // true
Feature::for(Team::first()->active('user-feature'); // false

That solves the values issue, as they would just show up as false.

However, it would be best if the all function only returned features that are supported by the type.

Feature::defined('user-feature', fn (User $user) => true);
Feature::defined('team-feature', fn (Team $team) => true);

Feature::for(Team::first())->values([
    'user-feature',
    'team-feature',
]);

// [
//     'user-feature' => false,
//     'team-feature' => true,
// ]

Feature::for(Team::first())->all();

// [
//     'team-feature' => true,
// ]

What do you think, @joshrainwater?

Yeah I like this; let's me still use some of the shortcut functions in cases where I just want to grab a list of all Team-level features in the few cases that it's the best thing to do.

Also adding an event trigger for trying to get a feature for the wrong scope eliminates some of the hesitation around ignoring a mistake being made.