A first thing would be to make your test case(s) accessible to us. This means that you'll have to at least find out one combination of module versions that has the memory leak. Preferrably, these are all the latest module versions.

As a second step, I would try to eliminate as much of Catalyst and KiokuDB as possible, and call the offending part of the code in a tight loop as to exaggerate the memory consumption as far as possible.

From my cursory look at Catalyst::Model::KiokuDB::save_scope(), it calls another subroutine, ->setup_scope_guard(), which already has caveats about memory leaks. So I would continue from the code in there - most likely, some callback is closing over variables that it should release.

Are you sure that your diagnostic tools likel Devel::Monitor and Devel::Cycle are applicable resp. work? Personally, I prefer to override the DESTROY method of classes to track when an object gets destroyed:

my $old_destroy = \&Catalyst::Model::KiokuDB::DESTROY;
*Catalyst::Model::KiokuDB::DESTROY = sub {
    warn "$_[0] destroyed";
    goto &$old_destroy;
};
[download]

together with a block at the end of the main program telling me when global destruction starts.