Hi Matthew,
In existing features in mojoPortal we don't use more than one ModuleControl per feature so any instance of a feature has one an only one moduleid associated with it. You basically have implemented 2 features and they will each have a different module id.
The way I would have approached this feature is the same as with any other feature, I would only have one ModuleControl that would be put on a CMS page. Then instead of the second control you have implemented I would implement a supporting page or pages for the other aspects of the feature and I would link to the supporting pages from the one ModuleControl and I would pass in the pageid and moduelid in the query string from the links in the ModuleControl to keep the same page and module context. Think of the modulecontrol as the entry point to the feature so there should only be one of them but a more complex feature will have supporting pages. The Html feature is a simple one with no supporting pages, but Blog, Forums, WebStore, are all more cpomplex features that have supporting pages and also implement search.
So for example maybe the select category control would be the one module, and from there I would have a link for "Apply For Membership" that links to a supporting page and this would pass in the pageid and moduleid as params.
This would make it a bit easier to implement the indexbuilder. I would suggest study the code for several index builders for different existing features to see what they have in common and also how they differ. This will give you a broader view and hopefully help you get ideas about how to implement one for your custom feature.
The indexbuilder is basically defining index items that are queued into a table and then the IndexWriter task is launched on a background thread and it processes the rows from the database mp_IndexingQueue table and writes to the actual search index which is a set of files under /Data/Sites/[SiteID]/index
The index items define the url will the result will be found and it also stores the allowed view roles, so when view permissions on a feature are changed the index must be updated. In your case if you hav eno security concerns about hwo can search then you could hard code the roles as "All Users". The main purpose of moduleid and item id in terms of indexing is giving the indexed item a unique key so that if the content changes the index can be updated correctly, ie by deleting the previous index item and then re-creating it.
Hope that helps,
Joe