This will probably never show up on a profile, but the runtime complexity is higher than it needs to be. I think it can be rewritten to have lower runtime complexity without a real change in readability.

Here's the runtime complexity of the code as written:

• For every item
• For every form
• Pull the builtin key out and test it.

So this has complexity O(number of items * number of builtin forms): for every item, we have to do something to every form. Neither of these is likely to be exceptionally large, but users could conceivably build a menu with 100 items and we might have 100 builtin forms in the future, so this would be ~10,000 operations. These operations are cheap, but I could imagine this taking ~5-10ms on a profile some day. And there's no upper bound to the number of items or forms that we could have.

A version of this code with lower runtime complexity is:

• Compute the getBuiltinKey map first, up front, before looping over items. It's the same every time, so we don't need to keep rebuilding it for every item.
• Use isset() and array keys to do a hashmap check, instead of iterating over the list every time.

That would look something like this, up top:

$builtin_map = array();
foreach ($form_engines as $engine_key => $form_engine) {
  $builtin_map[$engine_key] = mpull($form_engine, null, 'getBuiltinKey');
}

That computes the map once, which has cost O(number of builtin forms). Then, for each item, when we identify that the key is non-numeric:

if (isset($builtin_map[$form->getEngineKey()][$form_key])) {
  ...
}

Each test is a hash check and we do one per item, so this is O(number of items). So our overall complexity is now O(number of items + number of builtin forms) -- the sum of the terms instead of their product -- or about 200 operations instead of 10,000 for the "100 of each" case.

I think that code isn't any more complex or harder to read.

That said, this is definitely premature optimization so take it or leave it. We can adjust it if it ever shows up on a profile.

This stuff looks unused (you use $form_key instead, which is good).

• These arguments are in the wrong order ("needle, haystack" -- but strpos() takes "haystack, needle"), so I think the check won't work.
• strpos() can return 0 to indicate that the needle is at the beginning of the haystack. After correcting the argument order, invalid keys that begin with a slash, like "/abc" will still survive the check. You should explicitly test !== false instead.

Can this be private?

The name getIsDefault() is a little misleading, and we should probably change it to getIsCreateForm() or similar eventually. A form marked as a create form is not necessarily the default create form: the default create form is the first visible one in the ordered list of create forms.

So if you mark three forms "A", "B" and "C" as create forms, and order them in "A, B, C" order, this will mark all three as "Default Create Form", when "B" and "C" are normally not default create forms.

The default form is also viewer-dependent, so even if we label the first form, it might be misleading to label that particular form as "Default Create Form" when it really means "Your Default Create Form, As The Current Viewer".

Maybe just "Create Form".