Before diving into the implementation details, here is some feedback on the requirements:

1. I don't have a strong objection to performing class checks for object equality inspected with eql?, but can you provide a URL as a basis for this? I'm curious whether always including class comparisons in the overrides, as shown in the good examples, is logically consistent with the language specification.
2. == checks for object equality. I think performing class checks for == is excessive. For example, in cases like 1 == 1.0 #=> true, equality via == should be delegated to the context of the class. Therefore, please exclude this from the scope of the cop’s inspection.
3. The name Lint/UnsafeEqualityMethodDefinition feels off. Lint/ObjectEqualityOverride seems to be a better fit.

Before diving into the implementation details, here is some feedback on the requirements:

1. I don't have a strong objection to performing class checks for object identity inspected with eql?, but can you provide a URL as a basis for this? I'm curious whether always including class comparisons in the overrides, as shown in the good examples, is logically consistent with the language specification.

I don’t have anything ruby-specific at hand, but it is widely accepted that the :== binary relation (setting aside the minor differences between :== and :eql?) should be an equivalence relation, meaning it must be reflexive, transitive, and symmetric. Checking whether the argument passed to :== is an instance of the same class (via other.instance_of?) is a necessary, though not sufficient, condition to ensure these properties (it doesn't work in the case of kind_of? but people use it everywhere anyway).

Although the original motivation for this cop was to prevent runtime errors related to object comparisons (see the original issue), I firmly believe that the absence of class checks can lead to difficult-to-diagnose bugs. I recall struggling with a ruby-i18n-related bug after upgrading from Ruby 3.0.0 to 3.0.1, which was ultimately caused by a missing class check (see https://stackoverflow.com/questions/77830896/hash-related-behavior-mismatch-between-ruby-mri-3-0-0-and-3-0-1/77841475#77841475 for details)

Well, == and eql? are expected to be overridden for equality checks based on the context. In other words, whether they maintain identity like equal? by default or are used for equality depends on the nature of the class. Considering the convenience for users, I have concerns about enforcing such context-dependent usage uniformly through a Lint rule.

For example, I think linter that enforces overriding hash method whenever eql? method is overridden can be uniformly implemented. This is because it is specified in the language specification as follows.
https://ruby-doc.org/3.3.5/Object.html#method-i-eql-3F

Thanks, I understand your point now. Unfortunately, ATM I don't see anything related in the specification.

Fixed the issues you mentioned (#== and naming) just in case you think it worth merging. Lint now passes.

I understand the proposal, but something like this needs an iron-clad rationale before we can merge it. (mostly because I don't think such code is particularly common in the wild)

@rubocop/rubocop-core As usual, in such tricky situations your thoughts would be most appreciated!

This will likely register a false positive for methods along the lines of (&& could be ||, etc.):

def eql?(other)
  super && self.title == other.title
end

and similarly (where foo is another method in the class):

def eql?(other)
  foo.eql?(other) && self.title == other.title
end

or even any generic method call could do the equality check but not be visible:

def classes_eql?(other)
  other.class == self.class
end

def eql?(other)
  classes_eql?(other) && self.title == other.title
end

Another category of false positives:

def eql?(other)
  # where CLASS_NAME is the actual class constant
  other.is_a?(CLASS_NAME) && self.title == other.title
end