Nice. Approved.

Applied both suggestions.

Thanks for taking this on.

I disagree about the Vec thing, but it's a minor issue and not that relevant. I have two more important notes:

• The assertion messages are incomplete; the default for assert_eq in Rust is given as left == right, which is OK if you can see tests and know which is what, but on Codewars the user has no idea what "left" and "right" refer to. An added clarification is mandatory for that reason (or use assert! and roll your own).
• This would be a good opportunity to fix this ridiculous "should == result" phrasing in the description examples. I don't know what the author was thinking, but replacing an English word in a sentence with a logical operator is borderline insanity. Either should equal result or => result or something similar. At least change it for the Rust part.

Notes:

• Needs random tests
• Needs assertion messages
• The fields of PaginationHelper should not be given in the initial solution, it's up to the user to decide what the structure of their type needs to be, since that is an implementation detail.
• new() on the other hand needs a concrete signature. Don't make the user guess what arguments the tests are going to call it with.
  • I'd suggest making the input to new generic as well. "collection" covers more than simply vectors. The most useful thing here would probably be IntoIterator<Item=T>, and let the user's implementation handle taking ownership of the values (maybe restrict T: Copy).
• Domain and co-domain shouldn't be transcribed literally when translating to a new language. -1 is not an idiomatic return type for fallible operations in Rust. Any method that takes an argument that might be invalid should return an Option. Indices and counts in Rust are typically usize, so the return type of page_item_count and page_index should be Option<usize>
• All methods should have a todo!() macro in them, not //todo comments, otherwise they don't compile.

I'm going to reject this. Feel free to fork it and apply necessary fixes.

This was until now one of the best katas I've seen. Learned a lot and had even more fun!

Using split(markers) with spread operator is really ingenious, respect!

I've tried to make the good proposal by josdem a little bit more Kotlin idiomatic and added a generator for testCases, so that we can check solutions against 200 randomly generated list of integers