I think hiding singleton class from ancestors is better even when a modules is pretended.

Do you believe that only because you want to avoid all compatibility issues, or are there other reasons?

I believe it should be easy to fix the incompatibility of RSpec, for example by going through ancestors and skipping them until you encounter overriden_method.owner. It might even be easier if there was a builtin way to access super as suggested by John Mair [ruby-core:52266, no actual feature request].

I still believe that not hiding the singleton class is both the most consistent and the most helpful. With the advent of prepend, it makes even less sense to hide the singleton class.

Remember that this question arise only if you access the ancestors from the singleton class. I think it is fair to assume that one understands the existence of singleton classes in this case... I would guess that only fairly advanced libraries (e.g. rspec) would do so and they should be able to adapt easily.

I find it telling that the consistent singleton_class.ancestors makes the code much simpler. There is a special case handling that is no longer needed with it, see my pull request for rspec-mock: https://github.com/rspec/rspec-mocks/pull/257

Do you believe that only because you want to avoid all compatibility issues, or are there other reasons?
Just because for compatibility issues.
And I agree it is more consistent and helpful that the singleton class exists in ancestors in case of self is a singleton class.

My concern was about Module#prepend with a singleton class. How to mock o.m1 in the following example?