Priority.
Callbacks are chained. By default, every callback has a priority of 200. So without explicitely setting a priority the chain will be assembled that way that the first registered component which is using this callback will get 200, the next 201 ... and so on.

But since we currently have a bug, that this chain will break, if one callback is returning FALSE, and OssnLikes IS in fact returning false and is executed BEFORE your component, I gave your component's callback a higher priority. Otherwise it will be never executed. (This issue will be fixed in 5.2)

oh got it, priority.

So, the complete deletion part would look like

ossn_register_callback('annotation', 'delete', 'com_removeAnnotationMentionNotification', 199);
 ossn_register_callback('post', 'delete', 'com_removePostMentionNotification');
 ossn_register_callback('user', 'delete', 'com_removeUserMentionNotification');

and

function com_removeAnnotationMentionNotification($type, $params, $data) {
    error_log('ANNOTATION ' . ossn_dump($data));
    $notifications = new OssnNotifications;
    $notifications->deleteNotification(array(
        'type' => 'mention:comment:created',
        'item_guid' => $data['annotation']
    ));
}

function com_removePostMentionNotification($type, $params, $data) {
    error_log('POST ' . ossn_dump($data));
    $notifications = new OssnNotifications;
    $notifications->deleteNotification(array(
        'type' =>'mention:post:created', 
        'subject_guid' => $data
    ));
}

function com_removeUserMentionNotification($type, $params, $data) {
    error_log('USER ' . ossn_dump($data));
    $notifications = new OssnNotifications;
    $user = $data['entity'];
    $notifications->deleteNotification(array(
        'poster_guid' => $user->guid,
        'type' => 'mention:post:created',
    ));
    $notifications->deleteNotification(array(
        'poster_guid' => $user->guid,
        'type' => 'mention:comment:created',
    ));
}

I left the logs in place so you might follow what's happening

What does the 199 stand for?

Pooh ... it's a little hard to explain ...

Let's start this way ...
Basically every comment is represented by an Annotation record.
Just because of historical reasons (when you could comment on posts only), post comments were handled some way special. And that's why the callback 'comment', 'delete' exists at all.

If you have a closer look, you'll find that in the end in fact the annotation gets deleted - AND that the Annotation delete method comes with its own trigger 'annotation', 'delete'

That is: the comment', 'delete' callback is completely obsolete and should be removed from your component. Even more, the comment part can be removed from com_removePostMentionNotification because the 'post', 'delete' callback itself takes care of deleting annotations.

Instead , we need to register

ossn_register_callback('annotation', 'delete', 'com_removeAnnotationMentionNotification', 199);

What did you run into with the post delete callback, Im happy to help looking into it.

Yep, another great step forward, but still not complete. I stumbled upon an issue with Annotation deleting in general and reported that to Arsalan. Just in advance: the post deletion callback still needs some investigation and improvement.

I got those implemented and they great, thanks! 1.7 uploaded

So I registerd 3 separate functions like

ossn_register_callback('post', 'delete', 'com_removePostMentionNotification');
 ossn_register_callback('comment', 'delete', 'com_removeCommentMentionNotification');
 ossn_register_callback('user', 'delete', 'com_removeUserMentionNotification');

and here they are ...

function com_removeCommentMentionNotification($type, $params, $data) {
    $notifications = new OssnNotifications;
    $notifications->deleteNotification(array(
        'type' =>'mention:comment:created', 
        'item_guid' => $data['comment']
    ));
}

function com_removePostMentionNotification($type, $params, $data) {
    $notifications = new OssnNotifications;
    $notifications->deleteNotification(array(
        'type' =>'mention:post:created', 
        'subject_guid' => $data
    ));
    $notifications->deleteNotification(array(
        'type' =>'mention:comment:created', 
        'subject_guid' => $data
    ));
}

function com_removeUserMentionNotification($type, $params, $data) {
    $notifications = new OssnNotifications;
    $user = $data['entity'];
    $notifications->deleteNotification(array(
        'poster_guid' => $user->guid,
        'type' => 'mention:post:created',
    ));
    $notifications->deleteNotification(array(
        'poster_guid' => $user->guid,
        'type' => 'mention:comment:created',
    ));
}

Please note that using the subject_guid is a special case we can only use with comments below a post. We must stay with using the item_guid when deleting a separate comment. Place a mention comment below a photo, and you'll see that this time the subject_guid is an entity_guid and unusable.

So far I checked the deletion part only, and 1.6 has its issues. Looks like you got my remark too literally. ;) I said: when a POST gets deleted, all attached comment notifications have to be deleted, too. But 1.6 would delete ALL comment notifications and a post notification if just one comment has been deleted, because you're always running into the same code at the bottom.

Aside from that and in general: if a registered callback has been triggered, we know exactly who we are. Thus it's contra-productive to let different callbacks address one common function that needs to find out the type of callback again. In other words: if the code inside the function differs depending on the callback, it's much cleaner and faster to use dedicated separate functions for each callback.