Below is a summmary of the modules and/or distributions you may want to look at for managing reservations, for something that is not a room (or a variation of that). These modules have a stable release, and can be used for either D6 or D7 (quotes are from their project pages):
Availability Calendars (D6 or D7).
... allows you to add an availability calendar to entities. Example use cases are tourist accommodation, e.g. bed and breakfast, holiday homes or self catered apartments, and car or motor bike rental.
An availability calendar shows your customers at what dates your accommodation is still available and at what dates it is already booked.
Simple Reservation (D6 or D7).
... provides a simple and easy way to reserve items which can be created by the administrator. Examples for it's usage can be hotel rooms, boats, cars, airplanes, basically anything you can think of which can be reserved by one individual.
The module provides the possibility to create reservations for other users (dependend on the permissions), and provides also restrictions in the maximum number of reservations a user can make and a maximum time a reservation can be made in advance.
There is NO support for payment, booking and what ever one could imagine beyond the pure and simple reservation, and it is also NOT intended to create more than this simple functionality.
MERCI (D6 or D7).
... can extend any content type into a list of unique reservable items (like studios) or buckets of interchangeable items (like DV cameras). We followed the approach used by Organic Groups, Feed API, and Scheduler and added MERCI's configuration to the Edit tab of those content types.
Resource Conflict (D6 or D7).
... allows for users to book resources for use during events. For example, a student can book a microscope for use within their lab.
Booking Systems Comparison
Refer to Comparison of Booking System modules for a comparison of various modules related to bookings / reservations.
This comparison contains some other modules (not mentioned in my answer here) that might be worth considering also, e.g. in case of requirements that are slightly different (as compared to those in the question here).
How to pick the module that fits best
I've ordered my recommended shortlist above by number of reported installs. Though that is often a good first indicator, it should not be used as the only criterium to pick a module.
So do your homework to pick the right one for you. E.g. by using criteria such as those I often use for selecting module, as mentioned in the community documentation about Maintenance Scorecards.
Here is the intro about it (from that page):
... contains a list of 23 criteria (=28-5) that might help to evaluate
the maintenance and support of contributed modules. Below is an
attempt to apply those criteria to each of the native charting modules
...
Obvious, these scorecards are related to "charting modules", but the same criteria are applicable, IMHO, wheneven you need to decide between multiple modules.
Also note that I've ordered my shortlist above by number of reported installs. Though that is often a good first indicator, it should not be used as the only criterium to pick a module. So do your homework to pick the right one for you.
Disclosure: I'm the author of that community documentation page (partially inspired by the 28 criteria in the issue linked near the beginning of the scorecards paragraph),
I hope this does not violate the site's policy on self-promotion.
