Optionally pass node id as argument to embedded view

I'm quite unsure on this, because passing the NID to the view is the whole point of the category_views module - it's supposed to provide an alternative listing of a category, so having the ID of that category NOT passed to the view looks really dumb in most cases. You're supposed to set up a custom view for this purpose anyway, and having the ID of category as an argument is pretty straightforward way (as we *do* need to filter by that category). Requiring the user to set up his/her view to retrieve something from URL is worse usability (feels hackish), and might even break things in some cases - categories are nodes after all, and may be rendered through node API calls even outside the node path.

In the other hand, nothing stops you from definig additional arguments in the view (although I can't really see how are you going to populate these with data, with category_views not passing additional custom arguments, and node URL of the category not supporting additional arguments - if you add one, it's treated as comment-ID and that comment is rendered below the node).

Also you can disable content listings (in category_display), and add the embed as php-snippet to the category-node's body content, if you need something custom.

What is your use case? Seems like some sort of edge-case to me so far.

Another solution might be with Exposed filters, allowing the user to further filter the View. As exposed filters work with separate URL arguments (form with GET method), it's entirely possible to generate links with something pre-selected, without any interference with the Category usage of arguments. (For example, I have this setup working at find friends section on a site - it's a category with a view [standard usage of argument for category filtering], plus Exposed filters for further user filtering.)

Also it might be possible to disable content listing altogether, and re-do the simple embedding code as a php snippet in the category body content (php input format), with addition of another argument (which would most probably need to be taken from some other GET variable, to avoid interference with comments displaying on the category node, but that's tricky with current Views code). Downside is, that you'll need to do that for every category you have, and the output will get indexed for search.

Another route might be with CCK, with the nodereference field, i.e. Product references Accessory (or the other way around). That should be workable with a separate View too, although I didn't really try, and it avoids category dependencies completely.

Yet another idea might be having either Products or Accessories submitted as Categories (or other content type with that behavior, a la book pages) under a separate container, and tag the other group with these (in addition to your basic categories, that may well apply to both). You can then list the content via one or the other container - i.e. the "normal" categories will list both products and accessories (as these will be both tagged with these categories), and Accessories (being in fact categories in another container) will list related Products teasers right there on their pages, below own text (possibly using a view too).

Or something like that. There are potentially many ways to do such relations with Category/CCK/Views.