Previously, RBIMPL_ASSERT_TYPE() used Check_Type() only in RUBY_DEBUG builds. It raised TypeError, but only in debug builds. For people testing type mismatch using debug builds looking for a Ruby exception, this can be misleading -- the code could be missing a type check in non-debug builds if it is relying on for example RSTRING_LEN() to raise. Also, Check_Type() can obscure the true cause of error in debug mode. When type check fails because the object is corrupt, instead of crashing with a clear type assertion message, it can crash while trying to construct an exception object to raise. You can see this for example in <https://.com/ruby/ruby/actions/runs/9489999591/job/26152506434?pr=10985>, where RB_ENCODING_GET() is used on a corrupt object, but the crash happens later and says "Assertion Failed: ../src/vm_method.c:1477:callable_method_entry_or_negative". RBIMPL_ASSERT_TYPE() should assert right away. RBIMPL_ASSERT_OR_ASSUME() asserts when RUBY_DEBUG and assumes in release builds, as desired. This should help investigate flaky CI failures that show up as TypeError from `Kernel#require`, e.g. "'Kernel#require': wrong argument type false (expected String) (TypeError)". Same CI failure examples: - https://.com/ruby/ruby/actions/runs/9034787861/job/24828147431 - https://.com/ruby/ruby/actions/runs/9418303667/job/25945492440 - https://.com/ruby/ruby/actions/runs/9505650952/job/26201031314 The failure occurs with and without use of YJIT.