Index: doc/proposals/virtual.txt
===================================================================
--- doc/proposals/virtual.txt	(revision 5a0735ac69ae27bf168ba9944266e32fcd45785b)
+++ doc/proposals/virtual.txt	(revision da81e1d010ac441c7d9fbead80f54b6be912fe99)
@@ -106,4 +106,12 @@
 would have many ambiguities if it did support multiple virtual parameter.
 
+It is worth noting that the function pointers in these vtables are bound at object construction, rather than 
+function call-site, as in Cforall's existing polymorphic functions. As such, it is possible that two objects 
+with the same static type would have a different vtable (consider what happens if draw(line*) is overridden 
+between the definitions of two line objects). Given that the virtual drawable* erases static types though, 
+this should not be confusing in practice. A more distressing possibility is that of creating an object that 
+outlives the scope of one of the functions in its vtable. This is certainly a possible bug, but it is of a 
+type that C programmers are familiar with, and should be able to avoid by the usual methods.
+
 Extensibility.
 
@@ -145,2 +153,9 @@
 
 These behave exactly as the previous example but all the forwarding routines are automatically generated.
+
+Bikeshedding.
+
+It may be desirable to add fewer new keywords than discussed in this proposal; it is possible that "virtual" 
+could replace both "vtable" and "vptr" above with unambiguous contextual meaning. However, for purposes of 
+clarity in the design discussion it is beneficial to keep the keywords for separate concepts distinct.
+