diff --git a/src/proc/mobject/session/scope-query.hpp b/src/proc/mobject/session/scope-query.hpp
index 8568a72da..865114b2c 100644
--- a/src/proc/mobject/session/scope-query.hpp
+++ b/src/proc/mobject/session/scope-query.hpp
@@ -21,6 +21,23 @@
 */
 
 
+/** @file scope-query.hpp
+ ** Specific queries to explore contents of a scope within the high-level model.
+ ** This is an application of the QueryResolver facility, and used heavily to
+ ** provide the various search and exploration functions on the session API.
+ ** It is implemented by accessing a SessionService, which resolves the
+ ** queries by iteration on the PlacementIndex behind the scenes.
+ ** 
+ ** @see query-focus.hpp
+ ** @see query-resolver.hpp
+ ** @see scope-query-test.cpp
+ ** @see placement-index-query-test.cpp
+ ** @see PlacementIndexQueryResolver
+ **
+ */
+
+
+
 #ifndef MOBJECT_SESSION_SCOPE_QUERY_H
 #define MOBJECT_SESSION_SCOPE_QUERY_H
 
@@ -29,6 +46,7 @@
 #include "proc/mobject/session/query-resolver.hpp"
 
 #include <tr1/functional>
+#include "lib/meta/function-closure.hpp"  //////////////////////TODO
 
 
 namespace mobject {
@@ -206,5 +224,53 @@ namespace session {
     };
   
   
+  template<class MO>
+  class SpecificContentsQuery
+    : public ContentsQuery<MO>
+    {
+      typedef ContentsQuery<MO> _Parent;
+      typedef typename _Parent::ContentFilter ContentFilter;
+      
+      typedef Placement<MO> const& TypedPlacement; 
+      
+      typedef function<bool(TypedPlacement)> SpecialPredicate;
+      
+      class SpecialTest
+        {
+          SpecialPredicate predicate_;
+        public:
+          SpecialTest (SpecialPredicate const& pred)
+            : predicate_(pred)
+            { }
+          
+          bool
+          operator() (PlacementMO const& anyMO)
+            {
+              if (!anyMO.isCompatible<MO>())
+                return false;
+              
+              TypedPlacement interestingObject = static_cast<TypedPlacement> (anyMO);
+              return predicate_(interestingObject);
+            }
+        };
+      
+      SpecialTest specialTest_;
+      
+      virtual ContentFilter
+      buildContentFilter()  const
+        {
+          return specialTest_;
+        }
+      
+    public:
+      SpecificContentsQuery (QueryResolver const& resolver
+                            ,PlacementMO  const& scope
+                            ,SpecialPredicate const& specialPred)
+        : ContentsQuery<MO> (resolver,scope)
+        , specialTest_(specialPred)
+        { }
+    };
+  
+  
 }} // namespace mobject::session
 #endif
diff --git a/wiki/renderengine.html b/wiki/renderengine.html
index 0f6c8b181..aa1920752 100644
--- a/wiki/renderengine.html
+++ b/wiki/renderengine.html
@@ -3611,7 +3611,7 @@ Viewed as a micro program, the processing patterns are ''weak typed'' &amp;mdash
 <pre>a given Render Engine configuration is a list of Processors. Each Processor in turn contains a Graph of ProcNode.s to do the acutal data processing. In order to cary out any calculations, the Processor needs to be called with a StateProxy containing the state information for this RenderProcess
 </pre>
 </div>
-<div title="Query" modifier="Ichthyostega" modified="201006150322" created="200910171621" tags="Rules spec draft discuss" changecount="13">
+<div title="Query" modifier="Ichthyostega" modified="201006160220" created="200910171621" tags="Rules spec draft discuss" changecount="15">
 <pre>{{red{WIP as of 10/09}}}...//brainstorming about the first ideas towards a query subsystem//
 
 !use case: discovering the contents of a container in the HighLevelModel
@@ -3630,6 +3630,9 @@ The requirement is to retrieve one (or multiple) objects of a specific kind, loc
 This is a special case of the general discovery (described in the previous use case), but it is also a common situation in a general ConfigQuery (&amp;rArr; an object of a specific type and with additional capabilities...). The tricky question seems to be how to specify and resolve these additional conditions or capabilities.
 * in a generic query handled by a resolution engine, we might represent these capabilities as a nested //goal.//
 * if we approach the problem as a filter pipeline, then the condition becomes a functor (or closure).
+On second consideration, these two approaches don't contradict each other, because they live in different contexts and levels of abstraction. Performance-wise, both are bad and degenerate on large models, because both effectively cause a full table scan. Only specialised search functions for hardcoded individual properties could improve that situation, by backing them with an additional sub-index.
+__Conclusion__: no objection against providing the functor/filter solution right now, even on the QueryFocus API &amp;mdash;
+notwithstanding the fact we need a better solution later.
 
 ----
 See also the notes on &amp;rarr; QueryImplProlog