In core/string_api.php, string_get_bug_view_link() builds the status label for the link's title attribute with this call:

$t_project_id = bug_get_field( $p_bug_id, 'project_id' );
$t_status = string_attribute( get_enum_element( 'status', bug_get_field( $p_bug_id, 'status' ), $t_project_id ) );

However, the signature of get_enum_element() (in core/helper_api.php) is:

function get_enum_element( $p_enum_name, $p_val, $p_user = null, $p_project = null )

So $t_project_id is being passed as the third argument ($p_user), not the fourth ($p_project). Internally get_enum_element() forwards both to config_get( 'status_enum_string', null, $p_user, $p_project ), meaning the bug's project id is used as a user id when resolving the status_enum_string configuration.

Effect: the status label shown in the bug link tooltip does not honor a per-project override of status_enum_string, and the project id is mistakenly treated as a user id. In most installations the impact is negligible, because status_enum_string is rarely overridden per user and config_get falls back to the global value — which is likely why it went unnoticed. But it is still incorrect: a per-project status_enum_string override is ignored, and under specific user-level overrides the resolved label could be wrong.

Expected: the project id should be passed as the fourth argument:

$t_status = string_attribute( get_enum_element( 'status', bug_get_field( $p_bug_id, 'status' ), null, $t_project_id ) );

Notes:

• Confirmed present in the installed version and still present in 2.28.1 and 2.28.4 (latest checked), so this is long-standing, not a recent regression.
• The resolved-class computation a few lines below already resolves the project correctly, via config_get( 'bug_resolved_status_threshold', null, null, $t_project_id ) (project as the 4th argument) — which highlights the inconsistency in the get_enum_element() call.