domain_language rows in variable_store are not deleted when they should

at Config > System > Information

Switching priority to major since Home page is very important and such a bug would prevent anyone from being able to use this module.

Ok some precision. The problem definitely comes from the Domain+I18n Variables Integration submodule. What happens is the Default homepage field cannot be edited at all. I mean even if the field is not declared as a domain variable or multilingual variable. The default value always stays on node/1 even if I try to change it to node/2 or node/40085. When I disable the module Domain+I18n Variables Integration and I refresh the site information page, I instantly get my correct homepage node/2 or node/40085. As soon as I re-enable the module, I switches back to node/1, impossible to edit.

the problem goes away when I comment line 35 of domain_variable_i18n.module :

<?php
/**
 * Implements hook_language_init().
 *
 * Create realm during bootstrap but let it there until it will get the key set
 * after domain and language are initialized using hook_variable_realm_switch().
 */
function domain_variable_i18n_language_init() {
  //variable_realm_initialize('domain_language');
}
?>

but then multilingual domain variables like my site name don't work anymore.
what is this line used for?
anybody sees how to solve this?

Here is a supposition. I think I remember trying to set the default homepage field as a multilingual x domain variable just to see if it was working. But then I removed the multilingual part and wanted it to only be a domain variable. I never set it back to multilingual x domain variable again. And now it is neither multilingual nor domain variable. However, in my database, in the variable_store table, I see 4 rows (2 languages x 2 domains) for the variable site_frontpage with the realm domain_language assigned and the value node/1 everytime... Looks like these rows should have been deleted. I am gonna try to do it manually.

Solved! Deleting the rows did the trick! There definitely is something missing in the module that should delete domain_language rows when they should not be there anymore. Until then if you configure a field to be multilingual x domain and you then change your mind, looks like you need to update the variable_store table manually