So you really just want the relationship name to be exactly the name of the table it links to? I think that can be done with
rel_name_map => sub { $_[0]{remote_moniker} }
To clarify some of your earlier questions, the reason that the moniker options were not having the desired effect is that they only affect the class name itself. They are assuming that most people have lowercase table names that might be plural and they assume that the average person wants to convert those to camel-case perl package names that are singular. They never considered that someone might want camel-case relationship names.
The reason why most people don't want camel-case relationship names or attribute names is that Perl's naming convention serves an important purpose. There is a namespace clash between a package name A::B and a fully qualified method name A::b and as soon as you start using uppercase method names, you can run into messy name conflicts. You can see this in the documentation of Type::Tiny (or Types::Standard, I forget where exactly) where the author recommends that everyone always call constructors as "A::B"->new instead of A::B->new because the latter will break if there is a type named "B" imported into the namespace of package "A". Well, the real problem is that Type::Tiny encouraged people to import a bunch of symbols that start with a capital letter and have a high probability of conflicting with a package deeper in the hierarchy, and that those symbols remain in the package if you don't use namespace::clean; and then confuse perl's heuristics about whether you are referring to a package or calling a function. For DBIC relations it probably doesn't matter, because nobody is likely to want to define classes within the namespace of a Result class.
