When nsIFile.remove is called for a path that is already missing we return different error codes depending on the platform. See bug 1519184 for an example of where that has bitten us.
OSX and Linux return NS_ERROR_FILE_TARGET_DOES_NOT_EXIST. I haven't dug too deeply but I suspect it is a result of the unix implementation checking for the presence of a symlink first (https://searchfox.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#1026).
Windows returns the probably more sane NS_ERROR_FILE_NOT_FOUND.
We should either make all return the same thing or at least audit existing uses of nsIFile.remove to make sure they are checking the return code correctly.